Test Driven Development (TDD) – A practical example

By kamui 1 Jul, 2018 Leave a comment

Recently the development teams here have been improving their coding skills by taking on the challenge of Clean code, a practice by Robert C. Martin (Uncle Bob) who has a number of very informative clean code books and clean code videos practised by many developers and to improve the quality of their code, so they can code faster.

If you want to go fast. If you want to get done quickly. If you want your code to be easy to write, make it easy to read. The only way to go fast—is to keep the code clean.

― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

Clean code is not the topic of this post though, I’ll leave that for another day. Today I’m going over the practice of TDD – Test Driven Development.

It has a number of advantages:

  • The biggest and most important is that it eliminates fear of change – refactor or modify at any time with no fear.
  • Reduce debugging time by between 50-90% – imagine a group of developers and pick one, any time, sometime in the last minute everything that person was working on worked and all its tests passed. It doesn’t matter who, it doesn’t matter when. Being good at the debugger is not a desirable skill, being good at the debugger, means you are experienced at interacting with bad code.
  • Reduce defects
  • Unit tests are the best low-level design document. If you want to do something, you can just copy the test that does it.
  • Writing tests first will mean that you write code that is testable, in other words, decoupled.
    This in turn Saves time, reduces estimates, which reduces costs
  • Avoid the grand cleanup – which inevitably fails due to lack of tests.
  • Increased confidence in the quality of the code – in the example app, if the tests pass they ship it. Your tests are like a parachute to prove your system works, imagine you are working on the code a life support system that you yourself might need to use at some point. Would you trust a system with its tests, would you jump out of an aircraft with a parachute that has holes in it?
  • Writing tests afterword is procedural, it is required of you for your job, but it feels like extra work for little gain. You already know your code works, because you have manually tested it, the danger then is that you take shortcuts with your parachute.

The 3 Rules of TDD

  • Write only enough test code to make it fail
  • Write enough code to make it pass
  • Refactor then repeat

The cycle is only 30 seconds to a few minutes long but it leads to code which you can have confidence in, code which you can entrust your life to.

Take the following example, I’ve taken the liberty to fill in the first few steps as comments so you can repeat the steps and then expand on them.

The Example

Below, you will see the typical High School computing problem of building a calculator, the requirements are simple to start with but slowly grow with complexity, but this can easily demonstrate TDD. See the jsFiddle site for the example.

Requirements

  1. it needs be able to sum multiple values
  2. it needs be able to able to subtract multiple values
  3. it needs to be able to multiply multiple values
  4. it needs to be able to divide one value from another
  5. it needs to be able to work with floating point numbers
  6. it needs to be able to calculate the value of an input number to the power of another number.
  7. it needs to be able to calculate the square root of a value
  8. it should have the ability to take a string of calculation values and compute the correct result.
  9. it should be able to handle multiple operators at the same time.
  10. it should output values to 5 decimal places
  11. it would be good if it could have a text field and button that when pressed would validate and calculate a user input calculation.
  12. it would be good if it could generate the calculations from calculator buttons

The application is written in Typescript and uses Jasmine as the testing framework. It starts with the simplist failing test, implement the calculator class, which can easily be made to pass by uncommenting parts of the code above.

To simulate the cycle, uncomment each test one at a time then uncomment the respective code to make it pass. Repeat this process until all the tests pass and the begin the 3rd acceptance criteria “needs to be able to multiply multiple values”.

Write the failing test and then implement it in the same fashion.

NDC – Clean Coders Hate What Happens to Your Code When You Use These Enterprise Programming Tricks

By kamui 4 Aug, 2017 Leave a comment

I have recently been listening to a few of the NDC talks from around the world and the one today that has caught my interest is this one, Clean Coders Hate What Happens to Your Code When You Use These Enterprise Programming Tricks by Kevlin Henney.

I particularly liked the inclusion of FizzBuzz Enterprise Edition. For those that don’t know FizzBuzz is a simple programming challenge, that used to be and still is in some organisations an interview question.

The problem is

For numbers 1 through 100,

if the number is divisible by 3 print Fizz;
if the number is divisible by 5 print Buzz;
if the number is divisible by 3 and 5 (15) print FizzBuzz;
else, print the number.

It is not a difficult problem, and it can be solved in a few simple lines of code.


def fizzbuzz(n):
if n % 15 == 0:
return 'FizzBuzz'
elif n % 3 == 0:
return 'Fizz'
elif n % 5 == 0:
return 'Buzz'
else:
return str(n)

there are even more concise versions of this code but this is simple to read and understand.

What FizzBuzz Enterprise Edition does is humorously take certain enterprise software design principles to their extreme.