Snakes exploring Pipelines – A “System Engineering and Management” Project

Part 2: Initial Coding

This series of blog entries describes a student project focused on developing an application by using methods like pair programming, test driven development and deployment pipelines.

Onwards to the fun part: The actual coding! In this blog entry, we will focus on test-driven development. Like we learned in the course, the very first task to do was to set up unit tests with JUnit, and so we did. As a quick reminder (or an introduction) the basic concept of test driven development:

At first, write a test that fails, in our case in a separate JUnit class. Then, write just enough actual application code so that the test passes, again, in our case by using the “quick fixes” automatically suggested by Eclipse. The last step is to refactor the code in order to improve code quality, without adding any new functionality! These three steps form a single iteration. The development process consists of a constant cycle of these iterations until the entire application is done. Like a snake that moves in a circle. (Not really, but I’ve got a quota for snake-related puns to fulfill.)

If this process is strictly followed, there can be no part of the application without a corresponding unit test.

The first component of our game we wanted to implement was the basic Gameobject class, containing the coordinates of the object in question. The Gameobject class was planned as an abstract class, but implementing it this way right now would be premature regarding the process. For now, we wrote our first test in JUnit:

The setup method is in charge of instantiating objects to for the following test. Since the Gameobject class is completely new and empty at the moment, the test for gameObject.getPositionX() == 1 fails, obviously. Consequently, we use the displayed quick fix to create the method. Remember, we have to write just enough code for the test to pass, without adding new functionality! Due to this, we only modify the newly created method by returning 1 (as demanded by the test) instead of 0:

And there we have it, our first lines of test-driven coding. The following iterations consisted (among others) of creating classes for the snake’s body parts, head and food, all inheriting from Gameobject, as well as the Gamecontroller, movement mechanics etc, with every new or changed part of the code preceded by tests. In the beginning, this unfamiliar process required constant attention, in order to not “just quickly add” code without writing a test first:

However, after a while, and thanks to the power of pair programming, we managed to get used to the process and stick to it. The benefits were obvious at the end of the session: When we were done developing for the day, we were confident that we had well written, working, and tested code. Some of the tests for the code written until now:

But wait, there was one last thing to do: Pushing the code to our Github Repository! As the work done today was the only source of changes to the code since the last time, we only had to add the new files to the git index, committing the changes and pushing them to our repository (found here).

This concludes our entry for today. See you round next time, and don’t forget to write your tests.