CJ and I are collaborating to build an app that teaches you how to solve single-variable algebraic equations like this:
2x – 4 = 16
Our target audiences are kids and teachers, so it was obvious to us that this would be a mobile app. For me, the choice of development platform was also a no-brainer – Unity:
- Katherine and I had tinkered with Unity a while ago, so I was already familiar with it
- It can generate binaries for every platform we’re considering, and then some (XBox or PS4 anyone?)
- One of the primary programming languages supported was C#
- Unity integrates with Visual Studio (you can also use MonoDevelop, but if you know and love VS, why?)
- Unity has a flourishing user community
- I could get started for free
One of the very first things I figure out with any new development language / platform / IDE is how to build unit-tests with it. As it turns out, Unity has a built-in test-runner based on NUnit (yet another point of familiarity for me). The runner is available under the Window menu, but normally I leave it docked on the right side of the IDE.
Now the next step was figure out WHERE my tests should actually live. After a little digging I found an article on the Unity Test Runner. The test runner has two modes – Play and Edit. I started with Edit, and (as the article shows), there was a button for “Created EditMode Test”. I clicked it, and it created a folder called Assets/UnitTests/Editor. I tried renaming and moving the folders in that string, and kept on eye on the test runner – would it find my test if I put it in a folder called this?. As it turns out, the “Editor” folder has special meaning for Unity. I settled on a folder structure of Assets/Editor/UnitTests (inverting what Unity created by default), so I could add other Editor scripts later if I needed.
Now that I had the basic structure, it was time to get down to business, and start writing the logic for the game. Fast-forward several weeks and 450+ unit tests later, and I have a few observations about unit testing in Unity.
The integration between the Unity IDE and Visual Studio is fairly seamless. I can add a new test in the latter, switch back to the former (where it kicks off a compilation in the background automatically), and see it appear a second or two later. In Studio, there is a preset button for attaching to Unity, allowing me to debug through my test and business logic easily. The one minor quirk is how Unity reports compilation errors – subtly, at the very bottom of the Unity UI:
This stung me a couple of times – I would make some typographical error, miss this clue that my new code wasn’t actually compiling, and re-ran my unit tests expecting a change, only to find that the same test was failing because my new code wasn’t actually being used yet. To avoid this, I now do an explicit compilation in Studio, and let Studio throw up the errors and warnings I’m used to seeing.
As a whole, the test runner does its job reliably. One thing I’d change, though, is how it reports the current state of the tests. If you’ve already run your test suite once, and want to run it again, Unity doesn’t clear all of the green (and red) flags for the already-run tests. Unless something switches from red to green or vice versa, you really don’t have any indication which test is being run at the moment, how far it is through the suite, etc. There IS a progress bar that appears while the tests are being executed:
And once that disappears you know it’s done, but I’d prefer the test statuses to be cleared before each run so I can watch it work through the suite again, fresh.
I’ve also noticed that the tests run much faster if you keep the focus on Unity the whole time. More than once I would kick off a series of tests, and switch to some other window while they ran, and found my tests were still running long beyond when they should have (I’ve seen suites take 2-7 times longer to complete this way). Again, a relatively easy issue to avoid – don’t switch away from Unity while the tests are running – but an odd one.
Overall, I’m very happy with my choice of Unity.