Explaining Test Driven Development (TDD) Part 1: What is TDD?
Being a programmer today is not easy. You have to research almost every day to see what is new or what is trendy. Otherwise, you will miss out on an opportunity to improve your skills and technology stack. However, not everything is about new trends, frameworks, databases or languages. There are also techniques that can help us and improve our development process. These processes add steps in order to help us check errors and save us time and money in future enhancements that may need to be done. One of those “development techniques” or “development approaches” is called TDD (Test Driven Development). In this part one of my three-part series, I will explain what TDD is and why it is important.
Test Driven Development, what is it anyway?
According to John Callaway in his article “A Pragmatic Approach to TDD”:
“Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: requirements are turned into very specific test cases, then the software is improved to pass the new tests, only. This is opposed to software development that allows software to be added that isn’t proven to meet requirements.”
In other words, we can define TDD as a development process where we write test cases before we write code. It defines a cycle of six simple steps. These steps are really easy to follow and assure us that by the end of the project we will have tests for most of our code. That way we can check that everything is fine before we deploy to production.
The importance of tests…
To begin, in order to understand Test Driven Development, we must know the value of the tests in the code. As developers, most of the time, we don’t take the time to write tests for our code when we are working on a new feature. Perhaps we thought our code would never fail or, sometimes, in the rush of the business, we do not have time to write tests. If you don’t write tests, as a result, there is no way to prove that our code works as it should and bugs begin appearing in production. This is why good test coverage is important.
We should get used to including tests in our daily development process. Not because some requirement says that we have to, but, rather, because it is a good practice and it produces better quality code. It takes more time at the beginning, that is for sure, but later we reap great rewards.
The six rules of Test Driven Development…
We can summarize the whole process of TDD into six simple and easy steps:
- Write a test for a desired feature.
- Run that test and watch how it fails!
- Implement the feature (Just the structure, not logic yet).
- Run the test, and watch how it fails again!
- Implement the logic, syntax, etc.
- Finally, watch the test PASS!
As you can see in the above steps, we never create a function or write code before we create the respective test. If we follow all these steps before we push to production, we can be sure we have a high test coverage percentage of our code.
Now that you know what Test Driven Development is, stay tuned for TDD: Part 2 where I will show you a practical example of TDD and Part 3, where I will show you an example using NodeJS. If you have any questions about Test Driven Development or best practices please comment below and I will be happy to answer.
—
At Gorilla Logic we hire only the best software engineers. Think you have what it takes to be a Gorilla? Check out our careers section and follow us on twitter!
