
Test Driven Development — — for your Startup.
This article’s intention is to provide an overview of why you or your Startup should be using TDD.
To do something well is so worthwhile that to die trying to do it better cannot be foolhardy. It would be a waste of life to do nothing with one’s ability, for I feel that life is measured in achievement, not in years alone.
— Bruce McLaren
It seems that there is always a reason why a particular developer, project, team, or company is ill-suited to do test-driven development. You will have to rewrite the code, anyway, as our team develops a more nuanced understanding of the customer needs, so we can skip testing or doing a good job on this iteration. Those reasons are almost always wrong, but they make emotionally appealing excuses.
In a Startup what you do early on counts
As you begin to bring a product to market, it should make a strong effort to avoid developing a reputation for building unreliable products. Furthermore as developers write code, they start building the core of the company’s offering. That code will likely stay at the heart of the company for a very long time, even as the product changes to account for improved understanding of the customer.
I like to take the TDD approach. It’s really simple. Here’s how I approach Test Driven Development:
When starting a project using TDD, there’s a common pattern to create a special test to make sure we don’t break anything that prevents the regular flow from working
Test Driven Development:
1. Write a test. — The test will help flesh out some functionality in the code.Then, run the test — The test should fail, since there’s no code(yet) to make it pass.
2. Write the code — To make the test pass
3. Run the test — If it passes, then when you’re confident that the code you’re writting meets the test requirements
4. Refactor code — Remove duplication, prune large objects and make the code more readable. Re-run the tests every time we refactor our code
5. Repeat!
Red/Green/Refactor cycle of TDD.
Seeing a test fail means you know you have to change something in order to add value. If you write a test that can never fail, you have managed to create truly useless code. We describe each unit of the system through a failing test and make it pass with a naive implementation first. Then, we identify smells and refactor it if necessary so that we can keep the cycle over and over again.
Here’s the alternative:
1. Mostly follows the waterfall/big-ban process.
2. Very little emphasis on testing by developers.
3. Tests are almost developed as an afterthought.
4. Tests are mostly manual.
5. Huge emphasis on QA team.
6. Delivering quality software on time and within budget is almost accidental.
A good programmer is someone who always looks both ways — before crossing a one-way street.
