So this year is a very productive one with multiple exciting and long posts. 🙂
2021 started with a huge change in our lives, moving to a new home, solving many problems related to that. Therefore I had to leave my private developer life behind for a while.
Recently I started to look into the next steps along with my good friend Peter and figured out we should revive one of our game ideas. We’ll share details on it later on Uplezz.com. For now, let’s say we are trying to get up to speed.
From my perspective, this means that I’ve started to re-learn testing in Unity, and I’m trying to create a habit of using the Test Driven Development (TDD) approach during my experiments. It’s already much more visible that automated edit and play mode testing can save a lot of unnecessary digging on details I may not even think of in a given moment.
For example, imagine you want to create an engine for a rocket that relies on fuel, and it uses x amount of fuel on full thrust per second. Let’s say you want to ensure that fuel is consumed based on the current thrust level, so if you have 50% thrust, you should use x/2 amount of fuel per second, right? It turned out I had some leftover logic which made fuel consumption so unreliable it would create nightmares later.
Today’s experiment was to create visual indicators that the thruster engine is on:
- if thrust percentage is higher than 0, we really want to use the thruster, so turn it on
- if thrust percentage becomes again 0, we want to turn off the thruster.
So this means whenever the engine is on, we can show “fire” with a particle system, also an optional light. As I don’t want to enforce to have the indicators on the thruster, the idea is to check if there is at least one particle system or light and use the first instance as the indicator (if both have one instance, use both). Later I might upgrade the code to handle every light and particle system inside the game object of the thruster, but this is enough for me now.
The idea of using TDD is to write the tests first and write the only code pieces that will fulfill the tests. I was trying to use this approach many times in the last decade in my work but never was able to get the hang of it. With game development, however, it seems so natural.
I don’t know whether my tests are even close to industry standards, but this is how I approach it:
- create a dummy object
- add the component which I’m testing
- add components which are also used for testing
- set those components up
- change some parameters (like set the thrust percentage) and check what’s happening after that
- if the expected is happening we are happy
- always set a title for your assertion to enable yourself to easily understand which step failed if any
It turned out that writing the tests is the longer part compared to writing the code that fulfills them. I have two theories why:
- setting up a testing environment requires you to think independently from the code you want to write
- you can have a written specification or requirement, but figuring out the “what you really want to achieve” part during writing the test, that’s priceless and actually helps you later when writing the code.
That was the result of today’s session: beautiful green checkmarks on the tests. And how much time was needed to code the feature? Only a few minutes. Was that extended test writing worth it? If you think long term, you might see the time added as a huge issue, but I see the tests as an investment: I want to ensure that a code change doesn’t yield unexpected results. Will it prevent all possible bugs from appearing? Not, I already learned from work that bugs will always appear no matter what you do. But you can spare a valuable amount of time and frustration if you think ahead this way.