Demystifying the Test Driven Development

Ever heard of test-driven development?

What The Heaven is that?!

Let’s imagine. You just started a personal JavaScript (or Python or GoLang or whatever it is) project. Oh wait, how about making a car. That sounds easier to imagine. Ok, imagine you’re going to make a car, your own build car.

Part 1: Test the Car

You started by making the engine. Then the wheel, and the brakes, and the steer, etc. After all of the components are built, you started to assemble it to make a fully functional car.

But wait.. will it be really functioning? You gotta test it first before you call it a fully functional car, don’t you? Well then, let’s define a test defining that the car is functioning.

Well done, you’ve done the simplest test. You make the car component, assemble it to a ‘probably’ functional car, and test it. If that works, you’ll live happily. If not? Will you just throw the assembled car and start it all over?

Part 2: Test the Car’s components

Instead of testing it when you finished all of the components and assembles it, why don’t you test each component of it? The components also have their own functionality, doesn’t it? That’s mean each component can also be tested based on their own functionality.

With this, you can also make sure that if you want to change a component, you can just test the related components only, not the whole things.

Part 3: Paid someone to test it

Defining the test can be tiresome. You must define each of the functionality details and test it each time you make a change to a component.

The job is simply to define and run the test, as illustrated below

Part 4: Automate it

If you can automate it, why wouldn’t you? Usually, Quality Assurance has their own methods to test something and each they test the thing, they just follow their methods. But humans are lack of details and speed.

We can conquer it by automating the test using a machine.

RED GREEN REFACTOR

http://www.deniseyu.io

In test-driven development, you’re insisted to make the test first before you code something. This is what they call red. You convert the requirement to a test, which will evaluate the code is it functional or not (based on the requirement).

The green is when you implemented your code and pass the test. While the Refactor is when you alter the internal implementation but not changing its external behavior. This could because of optimization or cleaning something messy.

Test Double

Sometimes, when we want to test our code with some other code that perhaps not coded yet. Confused?

Well, take a look at this simple code

function a() {
  // some logic here
}
function b() {
  // some logic
  a();
  // another logic
}

Here, there are two different functions. The function b() is calling function a(). If, these functions are developed by two developers, or function a() cannot be accessed at the time we test the function b(), we have to simulate a() in order to test function b()

There’re four different types of test double defined by Martin Fowler:

• Dummy objects are passed around but never actually used. Usually they are just used to fill parameter lists.
• Fake objects actually have working implementations, but usually take some shortcut which makes them not suitable for production (an InMemoryTestDatabase is a good example).
• Stubs provide canned answers to calls made during the test, usually not responding at all to anything outside what’s programmed in for the test.
• Spies are stubs that also record some information based on how they were called. One form of this might be an email service that records how many messages it was sent.
• Mocks are pre-programmed with expectations which form a specification of the calls they are expected to receive. They can throw an exception if they receive a call they don’t expect and are checked during verification to ensure they got all the calls they were expecting.

Here’s an nice explanation about these terms:

Test Doubles — Fakes, Mocks and Stubs.