Section: Bowlmaster: 10-Pin Bowling
We leave this video having tasted from the Tree of Knowledge of Test Driven Development (henceforth, TDD).
As far as decisions go, this is what rational folks consider a 'bad one'.
Look, you've summoned one the infamous course challenges! Asking you to "read" a "Wikipedia" "article". You've had a taste - really the suggestion of a taste - and now you need more.
See what you've become? No rational person wants to read smelly articles. Only you, a forbidden knowledge gourmet, would want to do something like that.
No, don't apologize. It's too late for you. But perhaps with time and guidance we can turn this bad decision around. Perhaps I can assuage your craving.
There's no time to waste. In the interim, please be wary of Faustian bargains, crossroads bargains, bargain-bin monkeys' paws, and $5 Footlongs™ from Subway.
To the rest: prospective students, eager ones, blog visitors. By taking this course you will have the chance to learn about TDD in Unity and C#.
In the following paragraphs I hope to give you an understanding of what using TDD is like and explain what it is good for.
TDD is done in three phases that are best summarized in the "memorable Red > Green > Refactor loop". What are these "red" and "green" bits? It could refer, literally, to the symbols given by the NUnit Framework.
In order to answer those questions, let's first examine what makes TDD possible.
What is Programming?
Computer programming is an activity done by humans that gives a computer the power to make decisions. As the creator of a program you know what the program should do and can recognize when something goes wrong. In other words:
- You have expectations of your code (namely, expectations of the functions you write)
This is only natural. You are programming to solve a problem and you can recognize when the problem has not been solved correctly. A few other facts:
- Functions can report their output (for example, with a return statement)
- Functions can be run automatically (possible with the NUnit Framework)
Putting this all together, a test is nothing more than an expectation written in code. Shortly after installing Unity Test Tools (covered in the following video) you will write out a test like this:
- rolls is the input
- rollsString is the expected output
- FormatRolls() is the function we are writing.
- Assert.AreEqual() is the test asserting (testing) the equivalence of two values. In this case the two values are the expected output and the function output (the output or return value of "FormatRolls") respectively.
You can execute your tests by clicking "Run All" in the top right of the Unit Tests View (see ex. 1). This runs the code automatically. Of course, since we don't have a function called "FormatRolls", the test will fail.
This is the red phase.
Putting 'Driven' into 'TDD'
Our lack of code is not a problem. The test tells us how to proceed. It tells us several things:
- We are writing a function (inside the ScoreDisplay class) named "FormatRolls".
- "FormatRolls" takes a single argument, a List of rolls.
- When "FormatRolls" takes the input of rolls, its function output should be equal to the expected output, rollsString.
With this knowledge, we can transition from the red to the green phase by filling out the function so that the above criteria are met. Our expectations (tests) drive the development of the function. The first try at writing the function may be as simple as this:
This is the green phase.
Finally, as good practice, we shift our focus from writing passing code to writing neater, more elegant code. We refactor and close the first iteration of the loop.
Then we begin again from the first step and ask, "what else should my code do?". We broaden our expectations.
We write a new test.
Our second go around the loop may change our function to this:
TDD gives you the following:
A goal - You have an idea of what to write next, even if it's just a small change.
Historical feedback - Since you are constantly writing new tests you have a suite of examples. When you write code that breaks a previous test case you will see it immediately as a failing test.
Also, since your code has to pass so many tests and you refactor so often, you know that it is good code.
Automation - The code examples above are part of a bowling game. Imagine having to test your bowling game in the tenth frame and you have to knock down a certain number of pins. This means playing an entire game of bowling to test one situation. What if you make a mistake? You have to start again.
Setting up Unity Test Tools is worth it since you can:
- Test with the exact values you want (no human error)
- Simulate runtime cases without manual play (less time wasted)
About the Author
I'm Elijah Lape, and I'm taking the Complete Unity Developer course, Complete Blender Developer course, and Game Physics course. I'm also taking this introduction from Elizabeth Laurie (see her post here).
I am easily impressed.
Don't want to miss out on our future Unity articles? Subscribe to our blog and find them helpfully appearing in your inbox once a month!