Hey guys,
I love unit testing because it can help develop better code, serves as code documentation, and also helps to add change without breaking other systems.
Were you already thinking about using it? I opened the project and didn’t see any test case yet.
Using it in this project would also help people who are beginning in game development to better separate code in specific responsibilities.
I think that adding unit tests could be very valuable, right now I don’t think there’s much to test yet but as we start to progress it would be very useful to keep up with Unit tests and setup a rule of “don’t break the tests with your PR” at the very least. It would be nice to also enforce all new features to have unit tests added to them but I’m not quite sure how well that would work as I’ve not yet written any unit tests for a game.
@cirocontinisio what do you think about unit tests?
With so many programmers writing things on their own and fixing bugs, etc… I feel like having Unit tests will really help us from keeping any from breaking something by mistake.
It’s also a going to save time as people could test things on their machine before asking for a branch merge.
Having testable code also usually helps keeping code simple and modular.
Any thoughts on the subject?
@Sangemdoko I merged your thread in with this one since they’re talking about the same topic 
Thank you,
For those who are unfamiliar with unit testing in Unity (it’s not always straight forward with Monobehaviours) here’s a video from Jason Weimann:
It’s a bit long but I think it explains things quite clearly
I was about to start a thread on unit test and found out this one.
Few months ago I started a project and implemented a lot of unit test.
But in the end I thought I was doing too much.
I’m very interested in seeing, in the case of a game, what we should test and more specifically when it starts to be “too much”, that is when the cost of writing the test is bigger than what the test brings as value.
I’m familiar with “standard application” unit testing, but more with “backend stuff”, with no UI, no displayed objects, no physics, things like that.
I think its rare to write too many unit tests. It really depends on the amount of people working on a project and for how long.
I think the best approach here is to use this project to get some experience and learn from others. So writing too many tests won’t be a problem, it’ll show some people the benefits of testing and they might start doing it in their own project.
I think a good place to start would be to test the existing features.
So for example loading the test scene with the player and start mocking some input to make it move.
@MileyUnity Is it ok to import the Nsubstitue dll in the project for easy mocks of interfaces?
To be fair I haven’t opened the project yet, I’ll do so sometime this weekend hopefully
We need to be careful with testing at such an early stage of the project. Lots of things in are flux - writing tests for things that are intentionally only temporary will just slow things down by making people repeatedly need to fix the tests. (For example, creating input recording/replay tests based on the current CharacterController test scene would be a bad idea).
Actually, TDD is about testing at the beginning. The problem is the contrary, testing after code is made is more difficult. We should not be afraid of change when developing by test. The changes should actually be easier because we know where the code is breaking if a test breaks.
I would like to help with Unit Testing. I am relatively new to Unity and to unit testing. I will check out the resources and follow to see where I can help.
I was curious about test driven development too, sounds like the challenge here is there are still too many moving parts to have enough requirements to generate relevant tests first.
In my humble opinion, this project is too small to take benefits from Unit testing.
Also, making game code “testable” will increase its overall complexity, which is bad for dudes that just starting using Unity.
While I agree a vertical slice may not benefit much from unit tests, this is also a learning project. Even if it adds complexity, if the community has the bandwidth to get it done, teaching new developers good programming practices like this is still valuable.
I’m extremely familiar with TDD, but thank you
As @shuttle127 says, we do not have clear requirements at this point - we are effectively still in the ‘pre-production’ phase of the project, where the basic functionality is in a state of flux.
A test like “Can the player jump?” might be OK to write right now, because it’s very unlikely that we are going to remove jumping as a feature.
However, a test like “When the player jumps, do they reach a height of 2 meters?” is a bad idea to write right now, because that’s the sort of detail that is very likely to change. It will probably be a good test to have later, once we start locking down the level design, because changing the jump height at that point might affect the navigability of the levels in ways we don’t want.
I see… so we are still figuring out what the game will be and can be totally different in a few days.
Exactly. While we set some things in stone to give the project a direction, we also wanted to give you all the ability to steer it a bit in unforeseen ways.
(although I wouldn’t say it’s going to be completely different)
Never forget that this thing is going to last months, and at the moment we’re merely 72 hours after launch
I’d like to recommend something different that I’m currently using in my project - Test Scenes.
Idea is very simple, every test scene has only one (or few systems) to be tested. This will make sure that game code is properly decoupled and could be reused in different projects (most common issue is missing singleton :)).
Examples (scene names):
MovementTest
InventoryTest
EnemySpawnerTest
GameSettingsUITest
etc
This will allow everyone to work on their PRs in separate scenes, prefabs will be used to carryover changes from these scenes to the game.
Hi everyone,
I would also like to see Unit tests in the long run and I would prefer Test Driven Development.
As already mentioned, the project complexity will increase and might overwhelm developers at the beginner level.
But nobody knows, neither the total number of contributors nor the amount of developers, who will frequently apply some changes. I assume, that later pull requests will have long review cycles when no test cases are available.
Moreover, I would like to make a suggestion.
We could start a second project (code only!), use custom NuGet packages containing Unity DLLs and use Github Actions or some other build pipeline for automatic validations. The only problem might be, that the project structure will differ from the typical Unity style.
I could describe the steps, how those NuGet packages must be structured. But I do not know, if we are allowed to distribute Unity DLLs within a public repository. Moreover, the prototype for the second part (setting up the validation with Github Actions) will require at least one week. The final product, which should be understandable and usable for most developers, will require much more time. So my last question is, is there anyone who is thrilled in this topic? Even if one does not contribute to the main project! There might be a lot to learn for people, who want to apply for a job in the QA (quality assurance) or integration team of some company in the future.
Keep in mind though: The development is an ongoing process and not every developer will write Unit tests by themself or stick to further guidelines, which were developed by some guys of the community. Last but not least, it is not certain that we can keep up with the development progress.
In my second post, i just want to reply to @Kamyker
I do like your idea and I do something similar in other projects, too. But I presume, that your recommendation would violate the Contribution guidelines, as discussed here: https://discussions.unity.com/t/811837
[quote=“ironCookie, post:19, topic: 811053, username:ironCookie”]
the Contribution guidelines
[/quote]Sounds like pretty bad guidelines. There’s difference between messy prototyping scene/scripts and properly made test scene. Is Unity expecting to everything work perfectly out of the box? Testing changes by playing game itself will eat up a lot of time. Not to mention everything will be heavily coupled.
A month ago I was pulling out movement from FPS Microgame to my own project. It was a mess because of lack of Assembly Definitions and test scenes to force decoupling. In the end had to pull all scripts and remove not needed ones as that was easier to do then refactoring one class.