Test-Driven Development

As the title of this appendix tells us, we will be talking about Test-Driven Development (TDD), a term we haven't used anywhere in this book so far. I deliberately chose not to. Why? Because I wanted us to focus on the following topics that I wanted to discuss in this book:

• Why we should use automated tests
• When to use automated tests
• How to write automated tests

I didn't want anyone getting blocked by their knowledge of TDD, with it being a proven methodology, but also surrounded with skepticism. It makes sense, however, to pay some attention to it, as there are a number of practical parts of TDD that are worth drawing attention to. Hence, this appendix will not fully expose what TDD is. Rather, it will be a condensed description with annotations that point out parts that can be of value to your daily development practices.

In this appendix...

TDD, a short description

The shortest possible description of TDD is actually the term itself. It is self-containing. It is describing that, by using this as your methodology for your software application development, the development will be driven by tests. Tests need to be defined to drive the writing of your application code, and in this way, your tests are directly derived from the requirements. This is an often uttered one-liner to describe TDD in a nutshell:

"No tests, no code."

The ultimate consequence of this is that you will never build application code that does not have tests to it. And, as the tests are one-to-one related to the requirements, your application code should not have any undocumented features.

But this description is actually not the basic definition of TDD. TDD is defined only by the following two rules, and everything else is deduced from that...

TDD, red-green-refactor

Given a test list, the actionable steps are described by what has become the red-green-refactor mantra. Where red and green respectively refer to a failing (red) and succeeding (green) test, this mantra tells you to take the following steps:

1. Take a test from the list and write the test code
2. Compile the test code yielding red as the application code that is not yet there
3. Implement just enough application code to make the test code compile
4. Run the test seeing it probably fail, still red
5. Adjust the application code just enough to make it pass, that is, green

6. Refactor your code, either test or application code or both, one after the other, and rerun the test after each change to prove all code is still well (green)
7. Move to the next test on the list and repeat from Step 1

The red-green-refactor mantra urges you to get things done step by step and as efficiently...

TDD and our test examples

What if we applied TDD to our test examples in Section 3, Designing and Building Automated Tests for Microsoft Dynamics 365 Business Central?

To be honest, it wouldn't have looked much different, as a lot of the TDD principles were implicitly exercised as follows:

• By defining our customer wishes by means of the ATDD scenarios, we created ourselves a sufficient set of tests, that is, a test list
• By implementing our tests with the four steps recipe, we did the following:
  1. We took small steps
  2. We created a structure for each test based on the GIVEN-WHEN-THEN tags
  3. We constructed the real code to get it to work
  4. We ran the test, and if red, we adjusted the code till the test passed, that is green
• And even though not worked out in the test examples as such, as discussed at the end of Chapter 7, From Customer Wish to Test Automation - And Some More, I...

Summary

Wrapping up this appendix, I would point out that the value of TDD is that it shows that it makes a lot of sense to do you work in small steps, define tests before coding (ATDD), and take one step at a time obeying the red-green-refactor rule.