1000 unit tests

20 October 2014

The term Test Driven Development was introduced at Gamebasics about a year ago. To be honest, I was sceptic about its value. It’s great, in theory. But maybe it’s to time robbing in reality? Couldn’t our precious time be spent more useful than writing unit tests? After a year working with TDD, I noticed the answer is definitely no. Time spent on DTT is time being spent usefully. Before TDD, every new website built was a leap into darkness. We faced several bugs every single time. For every bug we fixed, two new ones seemed to return. It was time for something new.

Two specialists from TNO stopped by to advise us. They were very clear: automated testing is a must have. We started immediately. After a trial and error period, a TDD training (learning how to make tests) and creating test area’s, we are now at the point we can make tests for every piece of code we add to our project.

Unit tests are very clever. Firstly, during actual development. To make tests work properly, we had to think about our code’s structure. No more magic void functions. Every path, both negative and positive, have to be created. The functionality can be tested through unit tests, without having to start the rest of the application. After the code is used in the project, the tests are still useful. They prove the fact that built functionalities actually work. Should something change and a test fails, we can anticipate before a user notices something!

TDD is the future
Although, 1000 unit tests seems like a lot, it only covers a small part of our application. With our experience with using unit tests, I expect the next 1000 will be a lot faster. But only unit tests are not enough. User Interface tests (UI tests) are of equal importance.

Share this article