INTRODUCTION TO TEST DRIVEN DEVELOPMENT

Hi everyone, In this article I will talk about Test Driven Development. This article is the first part of my TDD series.

Test Driven Development (TDD) is software development approach.

TDD helps making code simple and bug free.

In a software development it’s natural to make mistakes. These mistakes will be shown in the production area. And your customers send the feedback about your code and your design but these feedbacks can take a long time and your project will be full of bugs. So in this point Test Driven Development provides feedback immediately in a few minutes. It helps solve the bug before push your code to the production area. So this is the answer that why should we use the Test Driven Development?

Test-Driven development is a process of development. It run before development. Hence, TDD sometimes also called as Test First Development.

TEST FIRST TEST FIRST TEST FIRST TEST FIRST TEST FIRST TEST

TDD cycles

1. Write a test
2. Run tests.
3. Change your code (refactoring).
4. Repeat process.

TDD process

As the example below the flowchart shows the Test Driven Development processes. The developers write tests before code. If the code pass the test then developer start writing code. This is the difficult part of Test Driven Development because of test first approach we try abstract things before coding. Although this situation seems difficult at first but allows us to recognize an architectural or structural error during the tests. When the project grows, the structural and architectural errors causing big errors.

Test Driven Development fixes all of these kinds of error before coding.

RULES OF TDD

Uncle Bob describes TDD with three rules:

1You can’t write any production code until you have first written a failing unit test

-You have to know when will your tests fail or pass. You should know all the pass or fail situations and try all of the options before writing a production code.

2You can’t write more of a unit test than is sufficient to fail, and not compiling is failing.

-It’s not necessary write a more unit test. It is enough to write a test to fail.

3You can’t write more production code than is sufficient to pass the currently failing unit test.

• Writing lines of code should cause confusion so pass the failing unit test is enough for your production codes.

“The fact remains: Good design is testable, and design that isn’t testable is bad.”
― Michael C. Feathers, Working Effectively with Legacy Code

WHY TDD?

1: When writing a test classes the developers imagine that the system architecture, system structure and design so the developers know that “Which class or methods is necessary which is not necessary? In this way unnecessary code is not written. So project cost is decreased because time is wasted only for the required classes, methods and codes.

2: Increasing the test coverage. Every module and methods includes a test class.

3: Thanks to test errors decreasing.

4: Tests are help us understanding how the system works. Namely it is the documentation of the system .

5: Less debug because tests prevent errors.

6: Design first.

How to do TDD?

• First of all as the diagram show above, first make a design and set all the scenarios.
• Write a test according to design and expected fail the tests.
• Write a code belong to tests. The main purpose of this step is not a passing the tests. The main purpose is the answering that “Does it satisfy the design requirements?”
• The last step test the codes.

MEANING OF COLORS ON TDD CYCLES

Red

The initial point of TDD is red.

Development team take the software and design requirements into failing tests. These requirements can be any of form. For example they should be acceptance criteria list, documentation or mock-up.

After convert these requirements to the test make sure that tests are fail before writing any code.

Green

This next phase is the development phase. The goal of this phase is make all the tests pass. Developers should start the writing a code that helps pass tests. They should only write sufficient code.

Refactoring

This phase is all about for cleaning the code. Developers clean the code to make it easily understandable. In this phase, developers run the tests after refactoring all of the code and they have to fix the code or tests until all tests are passed.

This flow should be used in a project commits. For example;

Add a tag at the beginning every commit message in Git:

1. Red in about every “Red” commits,
2. Green in about every “Green” commits,
3. Refactor in about every “Refactor” commits.

This helps find developers steps. Therefore, it can be easily roll back to a commit if there is a problem.

Some inconvenience of TDD

1: Test Driven Development learning curve is longer.

2:Without detail and careful preparation, test-driven development doesn’t work

3: Tests are should be the same importance as your code

4: Beginners won’t be a fan of TDD and should be careful when being a part of TDD process

Summary

Here is the basic knowledge you need to know about test-driven development for your project. All in all, this makes you focus on your task, make your project more powerful, think from outside the box, and ultimately make you a better programmer.

I will continue to explain test, unit test and unit test frameworks with an examples and code snippets in my next articles.

Any suggestions or comments are highly appreciated. Thank you!

Happy coding…