4 ms·

> Most organizations want to start work even while the final specs of the work are being worked on. Is that significant? Your tests can start to answer these u

> Most organizations want to start work even while the final specs of the work are being worked on. Is that significant? Your tests can start to answer these unanswered questions before you ever get around to writing implementation. Suppose you thought you wanted to write data in ASCII format. But then you write some test cases and realize that you actually need Unicode symbols. Now you know what your implementation needs to do. Testing is the spec. The exact purpose of testing, which in fairness doesn't have the greatest name, is to provide documentation around what the program does. That it is self-verifying is merely a nice side effect. There is no need for all the questions to be answered while writing the spec (a.k.a. tests). You learn about the answers as you write the documentation. The implementation then naturally follows.

giantrobot 4y ago
> But then you write some test cases and realize that you actually need Unicode symbols. Now you know what your implementation needs to do. If your customer decides they want/need ASCII your test is immaterial. The same is true for writing any tests before you've got a meaningful specification. You're just writing code to write code. At that stage it makes more sense to write a scaffold in the general shape of the task than a bunch of tests defining precise but made up requirements. Aspirational tests are great if you know exactly what you need to do. They tell you when you get there. If you don't know exactly what you need to do they're just wasted effort that get thrown away with nothing having been gained.
- randomdata 4y ago
  > If your customer decides they want/need ASCII your test is immaterial. Not at all. First, if your customer doesn't know upfront that ASCII is necessary, showing the customer how the program will work will help them realize that. The lesson gained from your test was useful in getting to get to that point. Second, your failed attempt at an interface that provides UTF-8 (or whatever) during exploration is convertible to a negative case that will fail if ASCII isn't used, documenting the customer's requirement for future developers. If the customer originally required UTF-8 and years later a changing landscape forced them to require ASCII instead, again your spec can be negated to help you ensure that you made the correct modifications to meet the new requirements. > Aspirational tests are great if you know exactly what you need to do. Whereas I would argue that TDD isn't all that useful if you know exactly what you need to do. In that case you can simple write the code along with unit/integration/acceptance tests that validate behaviour. TDD is about exploring the unknowns and answering questions – showing the customer how the program will function on the outside – before you waste time implementing all the internal details of a full program around UTF-8 only to be told when you demo it that the customer actually requires ASCII, potentially requiring massive rework. The latter is where you waste effort.

giantrobot 4y ago

> But then you write some test cases and realize that you actually need Unicode symbols. Now you know what your implementation needs to do. If your customer decides they want/need ASCII your test is immaterial. The same is true for writing any tests before you've got a meaningful specification. You're just writing code to write code. At that stage it makes more sense to write a scaffold in the general shape of the task than a bunch of tests defining precise but made up requirements. Aspirational tests are great if you know exactly what you need to do. They tell you when you get there. If you don't know exactly what you need to do they're just wasted effort that get thrown away with nothing having been gained.

randomdata 4y ago
> If your customer decides they want/need ASCII your test is immaterial. Not at all. First, if your customer doesn't know upfront that ASCII is necessary, showing the customer how the program will work will help them realize that. The lesson gained from your test was useful in getting to get to that point. Second, your failed attempt at an interface that provides UTF-8 (or whatever) during exploration is convertible to a negative case that will fail if ASCII isn't used, documenting the customer's requirement for future developers. If the customer originally required UTF-8 and years later a changing landscape forced them to require ASCII instead, again your spec can be negated to help you ensure that you made the correct modifications to meet the new requirements. > Aspirational tests are great if you know exactly what you need to do. Whereas I would argue that TDD isn't all that useful if you know exactly what you need to do. In that case you can simple write the code along with unit/integration/acceptance tests that validate behaviour. TDD is about exploring the unknowns and answering questions – showing the customer how the program will function on the outside – before you waste time implementing all the internal details of a full program around UTF-8 only to be told when you demo it that the customer actually requires ASCII, potentially requiring massive rework. The latter is where you waste effort.