Hello

Recently I have been thinking a lot about how to communicate the benefits of test driven development. I know I have spoken about it before on this blog, but I think it is an idea that needs finesse to communicate effectively. To me it seems to be a simple but powerful idea, almost an obvious idea and yet… I remember before I had heard about it. My younger brother was telling me how I needed tests in my game and I was hesitant. I tried it and I didn’t get it. Later I tried it again and I still didn’t get it. Now though I have absorbed the information I have now to deal with the curse of knowledge. So I think to myself - what could I say to myself back then to galvanise myself into action? It is not an easy proposition - any idea which requires us to rethink how we do things is going to be difficult to sell. Test driven development is a skill and so to use it effectively you have to learn how. That takes time and effort and in my case it was a pretty painful journey. The only thing that kept me going was a desperate need to find a better way. I wouldn’t blame anyone who would in the same situation give up on the idea - not because it is flawed but because it is very easy to misunderstand test driven development and go down a very different and painful road.

I would like to steer others away from that painful road and take an easier route to learning test driven development. Not just because it is a better way to make software, but because it is a better way of life. 

Let that sink in for a moment. I am saying the real benefit in the day to day experience when programming. Even if you don’t end up making better software faster - though I believe you will - I recommend it because it is an easier way to work. Once you get the hang of it and get your project ready for it of course. Moving an established project to test driven development is going to be a massive pain. Though not as much of a pain as just keeping going.

Test driven development is the way to agilely develop software, but fundamentally the process of being agile - that is making small steps towards achieving your goal is a universally good way to do things. I have been reading Ghibli’s Hayao Miyazaki’s book Starting Point which is a collection of musings about animation and I happened to notice he uses agile techniques to make his movies. Does agile by any other name (or no name at all) smell as sweet? Within his book he moans about how you simply can’t decide up front with a script what a good animated movie will be like (i.e. waterfall doesn’t work). Instead he works with his whole studio to refine the movie in small incremental steps. He starts with simple drawings then goes through cycles of revision to improve these drawings and eventually turn them into animation (sorry if that is a crude view - I don’t know much about animation). I also love how stresses that he hates the idea of dictating everything in the movie himself. He wants a happy team where everyone can pour their passion into the movie.

My favourite part is when he mentions that he is credited as a writer on many projects, but only because the role has to be filled. The actual story was created by working together with the whole studio in this agile process.

So whatever the medium of creation you need a way to be able to take small steps and test them for validity. Since a movie is something which a human watches, you test it by having a human watch it. If you are writing code a machine executes it, so your test needs to be something that a machine executes. Relying on human testing for code is like planning a holiday by flying to each possible destination and comparing them. It will be time consuming, costly and by the end you won’t be sure what part was the real holiday. When you rely on manual testing, ‘which test did you do with what version of the code?’ becomes a big problem. I have had massive bugs in my code simply because I thought I had tested that, but that was actually a previous test on a previous version of the code. To be clear I am talking about code here - a game is also something a person plays so it does require user experience testing - something I have been lacking in - but that will only be easier if you have proper tests for the underlying code. The game breaking because you forgot to manually test something beforehand will derail your testing session pretty quickly - trust me I have been there.

Okay, okay so I have proven I can make it sound good, but so what? Talk is just talk. I might convince you I am right but at the end of the day you have things to do. You’ll learn test driven development next week when you have time (but the week after you’ll say the same thing). With the permission of my boss I have created a repository which contains the helper scripts I use for testing, which I will slowly start to fill with examples of good and bad tests. In parallel I plan to blog about my experience in writing tests for work and for Illic.

The package is called ivai.testultilies and you can find it here:

https://github.com/Insight-Via-Artificial-Intelligence/UnityTestUtilities

If you are curious about the company I work for it is called: Insight via Artificial intelligence you can find the website here:

https://www.ivai.com.au/ (If you scroll down the AR/VR section you can see the first project I worked on.)

The purpose is to simplify loading assets for your tests and to provide examples of how to write tests in unity. When I first started this blog entry I was preparing to use the repository with Illic and I was going to walk through the process. I had intended to suggest that you fill in some strings by editing the script. Since packages are immutable that would mean copying the scripts into the project and losing the advantages of it being a custom package in the first place. If you read my last blog entry I was just talking about how much of a pain it is to have to manually update things if the names don’t match. Finally it would violate the MIT licence which requires the licence to be copied with the source code.

My next instinct was to try to use the default settings for the package with Illic. Which was a problem. The script would look for the folder which did not exist within Illic. Now I could rename the folders except… If you didn’t know if the rename operation in git is the same as deleting the file and making an exact copy with a different name. Which splits the history into two parts - the part of the file with the old name and the part with the new name. That makes it harder to track the history of the items which changed - which would be a lot of files for Illic. This is also a problem in my work project but for a different reason. In my work repository the root folder of all my code is “com.ivai.packagename” since I split up code as much as I can into reusable packages. This is to separate the VR/AR elements from the rest of my code so it can be tested easily - to have to build to the Oculus Quest 2 or HoloLens every time you want to test a tiny thing is soul and forehead destroying (the weight of the devices for hours of testing adds up). Now I have a way to set that part of the path in code, but it is annoying. How can I convince people that this is the easier way if my examples have any annoying set-up step? So I added in a config file and before I knew it I had worked for half a day refactoring work code.

I am somewhat amused by all of this because this is working with the simplified version of the script. I would ask how it came to this but, what tests the test utility script? A question I now have an answer for - it is the repository that houses it as a separate project. If all of this sounds tedious, well… What was my point? Was test driven development new and exciting? No that it was less effort. Which it is, I would have made this testing utility a lot quicker and with a lot less pain if I had used test driven development to make it. If you are interested you can at least make use of this hard work to create some tests for your project.

The secret is that no matter how magical a studio Ghibli film is, it doesn’t mean that the process to make it all magic and fun. Miyazaki is a workaholic, who barely saw his kids when they were growing up. Perhaps that speaks to the pitfalls of the creative industry or perhaps Japanese culture in general but if it can take that much out of you to produce greatness… do you actually have the time to press play fifty times and play through your level fifty times? I might not have any tips for animators but when it comes to programmers - if your computer can take any of that load off your shoulders, shouldn’t you look for a way to do that? I might not have kids yet, but I know that if I did I wouldn’t want them to grow up like that. Our time is valuable, which is exactly why I will end here. I already have my next entry in the works - I had to split this one in half - so look forward to it. I plan to talk about how to get started and write your first test.

Until then.