I have been trying to learn and practice more about unit testing and test driven development, but unfortunately
web is kinda lack of learning materials.
I’m kinda understand the fundamentals but I have still questions for like Dependency Injection , mocking Static or Unity classes ,what cannot be Unit tested, how to handle ui or input etc…
So is there any any practical example with decent code coverage, Open source projects from Unity or community ?
1 Like
I publish this repository. It’s MIT licensed.
It’s more catalog than practical. Also, since it is a sample of a Japanese book, it has not been translated into English.
Or see Unity Test Framework learning materials
https://docs.unity3d.com/Packages/com.unity.test-framework@1.3/manual/course/overview.html
1 Like
Thanks for the links looks like I missed Lost Crypt
https://docs.unity3d.com/Packages/com.unity.test-framework@1.3/manual/course/LostCrypt/welcome.html
Simply because I been looking 2.0.1 version’s documentation. 
So far, I had very little need for anything but testing the code that I write. At most, I sometimes make a subclass to expose private properties and that’s about it.
Done right, you learn to wrap away anything that doesn’t belong. For example, when you make a system that generates assets, then you’d have an interface that calls into a class that simply defers any and all calls to the AssetDatabase while the rest of the generation code is independent of actually writing it to the disk. Now if you don’t need or want Asset creation while testing, you’d provide a NoWrite class which merely logs these calls and verifies you aren’t passing in null or something, since you can and should trust anything Unity does (except when you make false assumptions).
I don’t feel like using one of the mocking frameworks to do that for me, as it adds a lot of ugly boilerplate code to tests and I don’t like stepping through that automagic behaviour either. It’s just too easy to just create a class and trim it the way you need it for a test.
And if a class depends on other classes of mine, I create instances of those and add them the way the public API expects me to. Because I want to be testing the code the way the user uses it. I learned that this is not the London school of testing, but the other one (Detroit?).
Stay clear of London school I would say, this seems to have too much background in enterprise apps with micro-service architecture. The other school has you test related classes through the main class, and that makes a whole lot more sense IMO. Whatever the dependent classes don’t execute through tests shouldn’t exist. Provided you aim for 100% coverage, which you should.
Honestly, I don’t have much real TDD experience. This is my first project that I’m learning and applying the discipline and I love it. I read a couple books, most importantly Clean Code, Clean Architecture - you’ll learn enough about TDD from those books. The thing is, I see other more technical TDD books and kind of worry why they go all the way with DI and mock frameworks for a web request class when it really leads to better design not using those tools but rather designing your classes only to make web calls through your own wrapper. That way, you can always decide not to make the actual request, or make AND log it, or redirect it to another local webserver or whatever. TDD helps to focus on designing classes the way you don’t need DI or mocks. Again, I don’t have much experience but after half a year or so it really feels like DI and mocking exist only because devs did not fully adopt / understand TDD to begin with.
I hesitate to share my current repository because it’s kind of a mess right now with tests failing. I’m in the middle of a major (and final) overhaul of the design, and this is because of what I learned applying TDD to the project’s development. With the overhaul and thanks to everything I’ve learned so far, I’m currently designing and hooking up many many stub classes to get the architecture designed in code, automatically visualized with PlantUML. Yes, I purposefully do it the OPPOSITE way and this feels great! You won’t ever make a design that simply won’t compile because you can’t have an interface in a native collection, or you can’t subclass a struct, or you can’t serialize a generic without specifying the concrete implementation type rather than the abstract. This is stuff the UML or any diagram will happily go along with and lead you to think you finally have the greatest architecture … and then it won’t compile. Unity has plenty of such code design traps by design.
So here’s v3 of the project and v4 I hope to be able to push by July and from then on, if all things go well, it’s just implementing what I already know but entirely test-driven.
I will definitely adopt a better test method naming convention (Method_Condition_Expecation) and rigorously apply TDD to the point that I won’t be using my stubs but rather create new versions of them through TDD.
Thanks for the detailed insights, and repo link @CodeSmile
That books was already in my planned list (I’m on Agile Principles from same author), I will look them soon as possible.
That looks interesting since UML another topic that I’m want learn.
Indeed, that’s why I’m looking for practical examples.