C# Class Structure

Class Structure has a lot of areas to talk about, but this is about how classes interact, and keeping it simple when possible. As the project grows, a lot of spaghetti code can be reduced and project splits supported by making sure your classes are easily separatable, easily testable. If you've never done unit tests, its a great way to understand the measure of complexity.
Please join Patreon / 79667318
Discord Link: / discord
#unity #unity3d #tutorial #videogamedev #gamedev #architecture

[@eengineer1able]

Great explanation

[@unitydev457]

This is great!
One part I'm trying to wrap my head around testing at this point is how to test for if a class receives an event without having to simulate the entire tree of logic that happens on the route to that event being fired.
The only thing I can think of that's reasonable (but sounds quite unreasonable and involves a lot of refactor) to achieve this goal is to make all the elements along the way more testable and have them test IF they fired their part, and I guess then also test for if the data sent by their event was valid or useful?
not sure if I'm on the right track or on a wild goose chase tbh, any advice?

[@dvsdev]

I'll respond shortly. But honestly there are a lot of potential directions this can go.

[@dvsdev]

Check out: ua-cam.com/play/PLnRmXj9gwMNeXK8RooTuKj6Jw92X8iCKP.html for more info on testing. However, I don't cover events too much in there.
AH, I think I understand what you are asking about, and if I'm right, you don't need to test it. ("how to test for if a class receives an event without having to simulate the entire tree of logic") I spent a day or two thinking about how to express testing events via a comment. :)
So, you are talking about testing the communications between multiple classes. If it is a tightly coupled class like MVC, then it can make sense to test the different tightly coupled classes together. But not here. (Assuming this is not MVC related)
For testing you typically want a test case to focus on only a single class. And it shouldn't have to pull in anything else, unless it's a utility of sorts for the test case itself. (e.g., simplify the initialization of some data structure)
When testing class A that wants to fire an event on referenced class B, you would only create Class A for testing. Typically you would use an interface to class B, so Class A would reference Class B through the interface. (including wiring up the event) You can use MOQ to fake interfaces, and simply report back to your test case that the event was fired. When an Event is more global, I'll typically be using an Event Manager, like DVS.Events (see: github.com/DanVioletSagmiller/Dvs), so Class A, just announces the event happening, the test case listens for that. Class B is never directly referenced. Then I would also test Class B, that when such and succh event are fired, that X happens.
They are separate test cases, each focused on their own class.
When you are looking at this from the stand point of an event being fired by a sequence of actions from many classes, that is typically not how to think about testing. Unit testing is isolated to a single instance of a class or method. There is also System Testing, which is focused on making sure business cases are executed. There is Manual Testing, which is probably more what you should be looking at for this. If you are worried about the stability of communications between two classes, then a manual test to validate might be more what you need. I.e. I click this button which should trigger X should trigger Y should trigger this UI to change. From a coding standpoint, we are typically most concerned that each individual class does its job without breaking down or damaging data.

[@unitydev457]

@@dvsdev this was so helpful Thanks for taking the time to write out all these thoughts on the subject for me. Greatly appreciated! It makes a lot of sense that what I'd be looking for in this scenario is manual testing. That's why it's been hard to wrap my head around unit testing for this, because it was the wrong solution haha. Having each part of the system test itself for its own unit tests but manual testing the bigger system makes so much more sense than what I was thinking.
Cheers thanks again!