Hello there.

I started to write this before Unity started talking about charging for downloads. I am aghast at the news and I will write my next blog entry about my thoughts (not positive), for the moment though I will still be talking in a Unity frame of reference.

As I mentioned in a previous blog entry I have wanted to have a step by step guide on how to do test driven development. I have been kind of putting it off until now, basically because it is like writing an essay. I have to do my homework and then do my best to make it nice and readable. It has felt too much like work and I have had a lot of difficult things to do at work recently. This is not to complain. I love my job - I get to work with a lot of cool tech. In particular there is no way I'd ever be able to use the HoloLens otherwise. The HoloLens is cool. It feels sci-fi to see a hologram of a person standing there or in the case of what I first worked on an aboriginal diabetes patient waiting for a foot assessment. The HoloLens however has a number of downsides, its price point for one but perhaps its biggest issue in my mind is… it is made by Microsoft. The fact that it is a Microsoft product means it uses the Universal Windows Platform and tries to force you into the Microsoft ecosystem. Which means as soon as that ecosystem doesn't provide what you need out of the box you have problems. It isn’t all bad as I am actually quite a big fan of the Mixed Reality Toolkit which Microsoft provides (good thing they stopped officially working on the new version of it, leaving it to the community to finish…). The real problem is the Universal Windows Platform (UWP). 

If you are unfamiliar with the UWP it is a special platform Microsoft designed so they could have something like the google play store for windows machines. It is universal in the sense that all Windows machines can run the applications though a special player, but very un-universal in the sense that the player has a special environment completely unlike a normal windows PC. Suddenly even something as simple as writing to the document file requires permissions to be set in the app's manifest and then an async call to be run upon actually writing to said folder. There are advantages to having a stricter permission mode, I just want to highlight how writing code as though you were working on a windows machine doesn’t work. Where it really gets hairy is when you want to say stream the combined holographic / video content to another app. Now you might think, oh I can just use Microsoft’s tools. Good thing that they have excellent performance… wait actually the HoloLens app is incredibly temperamental. It works poorly at the best of times and not at all the rest of the time. There is nothing like an inaccurate stream which has to be restarted constantly to sell a project to your client. 

You could use Microsoft’s remote assist but that is an expensive subscription and it binds you to their ecosystem. It’s okay you might think, we can use a library to stream the video. Ah but you have to remember that the Universal Windows platform isn’t really Windows and so you can’t use Windows based solutions to stream media. Microsoft realised this so they started to port WebRTC to the HoloLens, then gave up and depreciated it. 

Okay, so let’s take a deep breath. I am not actually here to complain about Microsoft or the HoloLens. This is just to set the stage. When we are facing a difficult problem we need to be careful and figure out the best tools to help us solve the problem. If we don’t we are never going to get anywhere. Besides, isn't it when we face the hardest problems that we most need the time and energy saving techniques? Okay so let’s go back to basics. In test driven development we have the red-green-refactor cycle. The first phase of the cycle is the red stage where we:

1. Write the test
2. Run the test
3. See the test fail

Then there is the green phase where we make the test pass and finally the refactor phase where we clean up our code and make it better.

If you haven’t tried test driven development that first red phase might seem a bit odd. “Write the test first!?!?” You might exclaim incredulously. I assure there is a good reason for it, which I will get to in a moment.

So we have the HoloLens and we want to write a test which gets us closer to streaming video from it. Okay so… ah… so there are APIs in the universal platform that allow me to access the camera. APIs that don’t compile in the Unity Project… Okay, so that’s a problem. But let’s put that to the side for now. How would we test the APIs on a normal windows machine? Oh that’s right, when you are using IO you actually want to create a wrapper class to separate those APIs from the rest of your code. Okay… So now my test is… Well I can test the wrapper code, but that isn’t actually helpful is it? 

Is this a big problem?

Maybe, but test driven development isn't about writing tests. I think it should be called experiment driven development because the actual goal is to design an experiment, perform it and then use that information to improve our system. Now you might feel like an experiment is too grandiose. Science class makes you feel as though there is something particularly special about them but… As Adam Savage says "the difference between science and screwing around is writing it down". The core of the scientific approach is about coming to opinion because of evidence. If science class at highschool makes it seem intimidating it is because scientists have careers tackling big questions. That and you tend to hear about physicists trying to uncover the mystery of the universe with particle colliders. No one talks about the scientific papers about the colour of belly button fluff.

Since the task at hand is writing code we don’t need a particle collider (or quantum physics for that matter). The principle is the same though - the best way to find the truth is to test it out. So we write/construct/code our test first - otherwise how can we know when we have succeeded? - and then we record the result. With Unity's test runner we only need to define the test and the runner will give us the answer. The great part of these experiments is repeatability, they are experiments we can conduct whenever we want. Unfortunately in the situation I am painting it is not possible to write tests like this. We still need to work experimentally - it is just how we conduct experiments changes. So instead of writing a test in code, I write down what I am attempting on a git board and what the results will be after. That way I know what I am trying, when I have succeeded and what I have tried.

How does this relate to Illic you ask? Test Driven Development shines in saving effort. Programmers are busy people, especially those of us who have jobs programming other things. We have to admit we are prone to making small mistakes or charging ahead before we know what we are trying to do. After a week of this I sit down and try to work on Illic. Illic is my passion project and it is very important to me. More than that though it is my hobby. Time spent in Illic is time I could be working on writing a novel, drawing, reading, learning new things or playing video games. Which is exactly why having a solid development process is so important. You make the most of your time, which makes you happy and when you are happy everything is better. So I implore you to take this seriously, it can be the difference between a great afternoon coding and weeks of pain.

I am sure that is enough for me for the moment. If you want to learn more about Test Driven Development I suggest watching the videos on Dave Farley’s Continuous Delivery Channel. It wasn’t until I watched videos there that all of this clicked for me.

Until next time.