Many companies try to introduce TDD through a 2-5 day TDD Training Program. But the foundational skillsets in Effective Tests and Effective Code are missing. TDD then doesn't work! How to solve this?
Thanks for this insightful article. I'm wondering, though, if testable architecture is a must-have to start TDD. I've got the feeling that with the right tools (I'm thinking about insights from the book "Working Effectively with Legacy Code"), we can make the legacy code testable (without having transitioned to a hexagonal or clean architecture). Therefore, we can apply TDD on the slightly modified version of the code (provided we know how to write effective tests and effective code, I agree on that).
"I've got the feeling that with the right tools (I'm thinking about insights from the book "Working Effectively with Legacy Code"), we can make the legacy code testable (without having transitioned to a hexagonal or clean architecture)" -- could you elaborate further on that?
Regarding my perspectives:
1. Strictly speaking, testable architecture is a prerequisite for unit testability. So this means, if we want to write unit tests, we must have a testable architecture. (On the other spectrum, if a team chooses not to have unit tests, then no need for testable architecture)
2. TDD, by definition, doesn't specify what kind of tests will be written as part of TDD. For example, in the first step, the rule is to make a failing test, but it doesn't say whether it's a unit test or any other test type. We could apply TDD with any type of test, as long as we work incrementally, writing a test first, writing some code incrementally, (and can refactor that code).
So taking some legacy project, what we *could* do is as follows:
- We *could* write "integration tests" targeting the REST API and effectively spanning the whole application (e.g. REST API, hits the controllers, and even hitting the real DB), and as long as we're doing that with RED-GREEN-REFACTOR then we are satisfying the definition of TDD. So in this case, we're applying TDD with REST API integration tests, there are no unit tests.
- However, the problem we'd face is that due to the slowness of test execution, the overhead of running tests (which is frequent in TDD) would be too high, and also the size of the increments would be bigger (incrementality in unit tests is able to be done at a finer/granular level)... and most TDD practitioners would be against this idea.
Thanks for this insightful article. I'm wondering, though, if testable architecture is a must-have to start TDD. I've got the feeling that with the right tools (I'm thinking about insights from the book "Working Effectively with Legacy Code"), we can make the legacy code testable (without having transitioned to a hexagonal or clean architecture). Therefore, we can apply TDD on the slightly modified version of the code (provided we know how to write effective tests and effective code, I agree on that).
What are your thoughts about that?
"I've got the feeling that with the right tools (I'm thinking about insights from the book "Working Effectively with Legacy Code"), we can make the legacy code testable (without having transitioned to a hexagonal or clean architecture)" -- could you elaborate further on that?
Regarding my perspectives:
1. Strictly speaking, testable architecture is a prerequisite for unit testability. So this means, if we want to write unit tests, we must have a testable architecture. (On the other spectrum, if a team chooses not to have unit tests, then no need for testable architecture)
2. TDD, by definition, doesn't specify what kind of tests will be written as part of TDD. For example, in the first step, the rule is to make a failing test, but it doesn't say whether it's a unit test or any other test type. We could apply TDD with any type of test, as long as we work incrementally, writing a test first, writing some code incrementally, (and can refactor that code).
So taking some legacy project, what we *could* do is as follows:
- We *could* write "integration tests" targeting the REST API and effectively spanning the whole application (e.g. REST API, hits the controllers, and even hitting the real DB), and as long as we're doing that with RED-GREEN-REFACTOR then we are satisfying the definition of TDD. So in this case, we're applying TDD with REST API integration tests, there are no unit tests.
- However, the problem we'd face is that due to the slowness of test execution, the overhead of running tests (which is frequent in TDD) would be too high, and also the size of the increments would be bigger (incrementality in unit tests is able to be done at a finer/granular level)... and most TDD practitioners would be against this idea.