Test Driven Development (TDD) for odo

What’s TDD? In simple terms, Write tests first.

TDD Workflow

Under TDD workflow, we write tests before writing feature code. Below is the workflow that is generally followed:

  1. Add a test.

  2. Run all tests and see if the new test fails.

  3. Write the code.

  4. Run tests.

  5. Rewrite code incorporating any changes and add new tests.

TDD process for odo

  1. Write tests for every feature or bug fix before implementing the code.

    • Developer splits the assigned task into small achievable sub-tasks

    • Each sub-task requires unit tests to be written before feature implementation

    • Open work-in-progress [WIP] PR with the tests written

  2. The tests should cover both positive and negative scenarios:

    • It would be good to have all permutations and combinations covered as much as possible to help cover the boundary cases

    • There is always scope to add more tests, they could be added once the feature has been fully implemented

  3. Write feature code and run tests:

    • Feature code should be pushed to the same WIP test PR

    • Feature code should be pushed only after pushing the unit tests

    • After the feature code is pushed, the test should pass

  4. Review process:

    • Ensure that the PR with code changes is accompanied by unit tests

    • Travis checks will be the point of determination

FAQs

  1. Will TDD slow down our development process?

    Initially it might feel that way, but over time, it brings advantages to the development process by reducing bugs, improving test coverage, and the development time spent fixing regression bugs.

    TDD is just a recommendation. Nothing stops you from writing your code before your tests (locally, of course!).

  2. Writing tests based on a new feature is easier.

    Writing tests beforehand (under TDD) helps identify the design limitations and corner cases in advance. Writing tests post development often limits us to cover positive cases. TDD will help us move away from that mindset.

  3. Can we follow the same process for big features too?

    Tasks involving big features should be split into numerous simple and achievable sub-tasks, and each of those sub-tasks should have test coverage.

  4. Should tests always be written first?

    That is the point. In order to follow TDD process, we need to look at feature development from a testing perspective. It will help us cover wider scenarios, beyond positive cases. Tests will also serve as a good validator during the coding process.

Learning resources

If you have not tried TDD before, here are a few resources to get started: