Guide On Basics Test Driven Development for SMBs

Ever since the dawn of the computer era, developers and bugs have battled for supremacy. For obvious reasons, it is an inevitable combat. There are times when even the best and the greatest developers also fall prey to these anomalies. No code is 100% safe. That's exactly why we perform testing on the smallest of software projects. Test driven development allows developers to test their code to make sure it does what it's supposed to and allows small businesses to develop projects of higher quality faster and significantly reduces their go-to-market time.

In this blog we discuss the basics of TDD or Test Driven development. First things first -

What is Test Driven Development (TDD)?

Test-driven development is a software development technique that entails you to write actual code and automated test code simultaneously. This ensures that you test your code and also empowers you to retest your code quickly and easily, as it is automated.

Why TDD?

Many a times you successfully move your code to production without any problems. However, after you’ve moved it to production, everything seems to collapse and you're stuck fixing a hundred holes in a sinking ship, with more appearing each passing minute. Not a great situation to be in, isn’t it?

TDD is the solution that was meant to allow making changes and testing them quickly and effectively. When a program has been developed with TDD, it allows us to make changes and test quickly and efficiently. Just run the automated tests, and Voila! there you have it! If all the automated tests are passed, then the project is good to go—if not, then it just means we disturbed something with the changes. By understanding the exact parts of the test that failed, we can easily pinpoint the change that caused the disturbance and this makes fixing the bugs much easier.

Some people might dwell on changing software and overthink elaborate designs, wasting lots of time upfront while trying to create the "perfect" scalable system and end up getting it wrong and going nowhere. This is what typically happened in the bad old days where an analyst team would spend about 6 months in just writing a requirements document and an architect team would spend another 6 months on coming up with a design and a few years later the whole project fails. This scenario is sometimes a reality even today!

 Agile preaches that we need to work iteratively, starting small and specific user stories;then eventually developing the software such that we get faster feedback on the design and its functionality from real users. The acronym INVEST help in the assessment of the superiority of a user story. If the user story misses to meet the mark in one of these criteria, the team may reword it, or even rewrite the old one.

A good user story should be:

• "I" ndependent (of all others)
• "N" egotiable (not a specific convention for features)
• "V" aluable (or vertical)
• "E" stimable (to a decent approximation)
• "S" mall (to fit within an iteration)
• "T" estable (in principle, even if there isn't a test for it at present)

 TDD enforces this approach.TDD encourages a methodology of continually refactoring and delivering iteratively.

 Learn more about the pros and cons of TDD in our blog on advantages of TDD. 

How does TDD work?

 Test-driven development, or TDD as we'll call it henceforth, orbits around a short iterative development cycle that goes something like this:

1. Prior to writing any code, you must first write an automated test for your code. While writing these automated tests, all possible inputs, errors, and outputs must be taken into account. Following this ensures that your mind is not clouded by any code that has already been written.
2. Ideally, the first instance where you run your automated test should be a failed attempt—indicating that the code is not yet ready.
3. Subsequently, you can begin programming. Also, as you already have an automated test now, as long as the code fails it, it means that it's still not ready. This code can then be fixed until it passes all assertions.
4. As soon as the code passes the test, you can begin cleaning it up, by refactoring. As long as the code still passes the test, it means that it still works and you no longer have to worry about alterations that introduce new bugs.
5. Start the whole thing all over again, this time with some other method or program.

In conclusion:

Testing is a vital part of the development cycle, however, it's also one of the first thing to be cut when deadlines are looming.

If you are working on a software project and you need help with Test Driven Development, please contact us, we will be happy to discuss your project!