Test, Drive?

It’s just like test driving a car, you see. The salesperson asked what do you feel after riding the pre-released car. Your feedbacks and evaluations will be processed with others, probably by the RnD team, to finalise the final specifiactions of the brand new car. The thing is, before the test drive session commences, the car in subject must be produced first. This is different than the actual topic that I want to address. It’s about one of the most mainstream — if not, essential— practice in software development, not automotive development:

Test Driven Development

Just a little play of words between the title and the topic, there. Test Driven Development, often abbreviated as TDD, is a discipline in software development that prohibits us from writing our code before writing the test first. Notice the word ‘prohibits’ there, it seems no one is allowed to produce something before it was tested, right? Correct.

I bet several other engineers (not software) are puzzled by this practice, “How the hell you test something that hasn’t exist yet?”. Test drive in automotive makes sense, you test a product (a car) to candidate users and gain feedback about your prototype. And then iterations of updating the spare parts or other fancy mech stuff can begin from those evaluations.

But, software. We all know software is the new big thing, right. Updates are always possible to a software. It never degrades, because it exist within the degrading hardware, a computer. So you could test your software by gathering candidate customers right? Just like test driving a car, your software had to exist first, you have to produce the software first. Wrong.

I believe, even in mechanical engineering, car manufacturing in particular, compartments and parts are tested before assembled to a car. The test here could be anything, but it ensures that it passes all standards and safety measures to become one with the car — the product. So… you could say that the test routines to test the compartments had to be established first right? You won’t know how to produce to company standards if your company haven’t figured the standards yet.

That’s exactly the idea of Test Driven Development. Any software engineer must establish their test routines for each software they gonna produce. But is there any convention on how to do TDD? Is there any specific software or tool to do it? So without further ado, let’s get into the technical stuff regarding TDD.

The Goal

The test routine that we made have to represent the behavior of our programs. As a software engineer implementing TDD practice, your primary goal is to think through your software requirements or design before you write your functional code. By writing tests, you can then use them as a guide to implement your code. Furthermore, this method allows us to prevent bugs in our code because the code that we write is created based on the test. It has to pass your test, your requirements, your standards. And it made other developers aware the behavior of intended code functions before we implement it. It’s not only meant for you, software engineering always require teamwork, you know.

Like a traffic light

To remember the steps of implementing TDD to your software development routine, just think of a traffic light (speaking of cars!). What comes to mind regarding traffic lights? The colours. That’s what TDD phases are

Red

Red means stop, don’t move, don’t do anything; but that’s on the streets. Red in TDD means

Writing a test on something that we want to implement so that when the test is run, the result will be ‘fail’

That ‘something’ is the code you want to produce. Keep in mind developers don’t often build a whole software in one go. Just like a car, you need to manufact the small compartments, spare parts first. So the tests you will need to make is those that test compartments of your whole software. In this way, tests are made modular, just like the software parts. Each test represents one standard regarding one compartment. And it guarantees that all the tests together will cover all parts on the software, hence the term code coverage. Making a modular unittest but maintaining a high coverage is quite the challenge.

But why ‘failing’? Well because, you haven’t produce anything yet. Of course the test will fail where there’s nothing to test. But by standard, the test suite is prohibited to fail as a result of there’s no source code at all. The tested source code had to exist, but just leaved empty except stubs to make the code alive. But failing the test. Stubs are usually empty function with default return values.

Green

That’s Yellow.

I know. But hear this, the next step in TDD methodology is called ‘Green’ but I always depict it as a Yellow light in traffic lights. Yellow light in the streets means you’re supposed to be ready to either stop or go. In TDD, it’s the gray area where you’re not expected to quit producing but not expected to continue producing code either.

In simple terms, Green means “writing an implementation just enough so it will pass the tests prior in Red phase”. Notice the phrase ‘just enough’ there, it implies that you only write essential logics in your source to ‘just pass’ the test. This means no design patterns, no documentation, etc. You must only implement the code for the tests you have written. Although it sounds ‘just’ simple, you need to make sure all test requirements regarding that functionality (compartment) are fulfilled, no turning back to Red.

But although passing all test requirements, shouldn’t you be getting that Green light, as in traffic light, that means go? Not necesarrily. Keep in mind that software engineering often requires team work; you don’t code alone! It matters on the next phase of TDD.

Refactor

This is the green light. In the streets, you can finally go. You can finally deliver your functional source code to the software you’re working on, perhaps assemble it with other functionalities. But why not do this in the Green phase? I mean, your code’s working just perfect, it passed all the tests. There should be no harm when you assemble it to the other parts.

Refactor itself means rearranging your code with a design pattern, or renaming variables, or even adding spaces between the lines of code. And in TDD, Refactor means “fixing your code quality that maybe has been abandoned due to only focusing on making the test pass, without making the test fail”. Just like I mentioned earlier, building a software often requires a team, it’s not only you who determine tests, who implement functions. To enhance code understanding between developers, all of the personells have to ensure good code quality in their deliverables. To improve code quality, developers often recognize code smells and fix it so it will be clean. Refactoring code smells relates heavily to Clean Code paradigm which I’d explained on a different post (it’s not in english, though).

So you may now realize this last phase is important especially if you’re working together in a team. Your compartment that you made could be used by other members. Hence, they must take their time understanding your code. And the longer they took to understand yours means your code quality isn’t good enough. You should do refactoring, but make sure that it will not fail the test! That’s a common mistake in TDD. You went back to Red just because of your good deeds of improving code quality.

And, again, just like driving in the streets, you will stop by another traffic light again. You will always go full cycle when you’re implementing this methodology in your sofware development life cycle. When you are asked to make a new functionality, a new compartment of the big project, you must always start over again to Red, and Green, and Refactor, Refactor, Refactor.

Benny William Pardede

Koneg Liquid DevOps