Thoughts on TDD

Tests and Requirements

Tests and Requirements

Java TDD Bugs Requirement
Post originally published on dev.to.

Thoughts on TDD

Tests and Requirements
A very simple Test Driven Development Tutorial

In the last days I’m facing a huge question: With several teams working with several projects, how to avoid new bugs?

In the company that I work, we have a lot of microservices, but there is no owner. Probably someone can start working in a project and a new feature should be added in a microservice. When this happen, no bug should be added to any service in any client!

In this post I will describe how we are handling features changes with TDD.

TDD process review

When using TDD to develop any software we must:

  1. Configure Testing Frameworks
  2. Write a Test that fails
  3. Write the code that fixes all the Tests
  4. Refactor your code if necessary

This is what we call Red-Green-Refactor. First you make a test fail, then you fix and at least you improve your code organization.

RGR Process

Some thoughts on Red-Green-Refactor

Red-Green-Refactor most of time is used for Unit Tests. And this lead some questions about requirements:

When someone change your code

If we are talking about Unit Testing, this questions is not applied, because we are testing a class or a small piece of code. One change on this piece of code can change all software behaviour.

Create Test for Requirements

For all types of tests, none apply for requirements, they are all named according with the implementation components:

But… This names can mean nothing, we can create test for any purpose we want! So, I’m proposing a new kind of test: Requirement Test… Ok, it already exists! No problem.

class UserTests {
   @Test
   @DisplayName("It SHOULD allow create Users without a name")
   void createWithoutNameTest() {
       // Do the tests
       fail();
   }

   @Test
   @DisplayName("It SHOULD only requires username and password")
   void createWithMinimumPropertiesTest() {
       // Do the tests
       fail();
   }
}

It is important to keep this tests in all changes, because this tests keep a memory of all requirements.

Tips

Conclusion

Most of TDD approaches always talk about unit testing, but unit testing does not prevent you of any undesired requirement change. For that we purpose a Requirement Test. All requirement should be written as a Test. If any failed it cab be:

Thoughts on TDD

Tests and Requirements
A very simple Test Driven Development Tutorial
Originally published July 24, 2019