iToto's Blog

A Montreal based full-stack web developer who loves learning and trying out new things. This blog is my attempt to document my work as well as a place to discuss ideas or topics that I find interesting. Feel free to follow me on linked social networks.

TDD and clean development

Definition:

Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards.

Wikipedia

Why I started doing TDD

There are two reasons why I started doing TDD:

Firstly – like everyone else – I've been noticing the buzz around it and how people rave that "everyone should be doing it". So I figured I'd like to find out what all the fuss was about.

Secondly, I recently started a new job where my team wants to start doing TDD on all new project. Fully supportive of this notion, I was assigned a new project and started my TDD adventure. What better way to start TDD then on a clean slate, right!

Overview

The part that attracted me the most to TDD is that it forces the developer to work around unit tests. In my honest opinion, unit tests are a critical part of software development. It gives the developer a sense of security that the code they just added didn't break existing functionality. When working on large projects with other contributors, stepping on people's toes is imminent. In situations like this, unit tests - along with continuous integration – can be like guide rails to help keep you in bounds and prevent you from releasing a new feature that might have inadvertently broken a existing features.

First Impressions

One thing is for sure, getting into the discipline of writing tests before writing any logical code takes some time. Especially for me, as I'm one of those devs that likes to start writing some code as soon as possible. But, once you get the hang of it, it's actually really helpful. It forces you to put some thought into the design of your code before you start writing any. The workflow that I'm currently using is:

  • Start off by drawing a quick high-level data flow diagram.
  • Class design with functions needed (just the stubs).
  • Write my unit tests for each of the functions.
  • Start implementing the functions.
  • Commit on the completion of a passing unit test.

Clean Development

I also started using Grunt for running some general tasks.

Successful Grunt output

Lint and Code Sniff errors

Unit Test Errors

These tasks consist of

  • Running unit tests
  • Checking for syntax errors
  • Code sniffing for PSR2 code style validation

Coupled with a pre-commit hook, I am now sure that each commit is clean and free of careless errors. Code sniffing also allows for the codebase to follow a standard and prevents the project from turning into some scary mishmash of all the developer's preferred coding styles. For those interested, I created a initial Laravel 4 framework with my grunt setup on my GitHub. Feel free to fork it.

Conclusion

I really feel good about working with my new workflow. Knowing that my code is automatically being tested, sniffed and linted before each commit is comforting. Also,TDD keeps me on track with which functions I have to implement and what they should do.

If you're a developer thinking of whether or not you want to jump on the TDD wagon, I suggest you wait for the opportune moment and give it a shot. It might be frustrating in the beginning, but once you get used to it, it's really effective. I find myself becoming more productive as I have become better at writing tests, implementing and re-factoring my code and thinking before coding. It really is an efficient way of writing code.