3 ms·

You make a good point about not being able to enforce that TDD is actually followed. The best we could do is check that unit tests exist at all. In theory, if

You make a good point about not being able to enforce that TDD is actually followed. The best we could do is check that unit tests exist at all. In theory, if TDD really reduces the number of bugs and speeds up development you would see if reflected in those higher level metrics that impact the customer.

tippytippytango 4y ago
Exactly, if it made a big difference to profitability then it would be evident in the market place. TDD shops would out compete the ones that don’t use it. This doesn’t seem to happen in the market. What that means, if TDD is a benefit, it is such a small benefit that other factors in the business eclipse its impact.
agloeregrets 4y ago
> In theory, if TDD really reduces the number of bugs and speeds up development you would see if reflected in those higher level metrics that impact the customer. The issue is that many TDD diehards believe that bugs and delays are made by coders who did not properly qualify their code before they wrote it. In reality, bugs and delays are a product of an organization. Bad coders can write bad tests that pass bad code just fine. Overly short deadlines will cause poor tests. Furthermore, many coders reply that they have trouble with the task-switching nature of TDD. To write a complex function, I will probably break it out into a bunch of smaller pure functions. In TDD that may require you to either: 1. Write a larger function that passes the test and break it down. 2. Write a test that validates that the larger function calls other functions and then write tests that define each smaller function. The problem with these flows is that 1: Causes rework and 2 ends up being like reading a book out of order, you may get to function 3 and realize that function 2 needed additional data and now you have to rewrite your test for 2. Once again rework. I'm sure there are some gains in some spaces but overall it seems that the rework burns those gains off.
- UK-Al05 4y ago
  You shouldn't test those smaller functions. They're internal details. They should be private.
  - iratewizard 4y ago
    You also shouldn't test business logic. Your test code is more likely to be a liability than an asset when it isn't testing your codebase's core infrastructure.
    - klysm 4y ago
      I totally agree with this. In practice, I see much more value in tests that fully utilize your dependencies. The hard part is tying all the shit together and not getting weird stuff on the boundaries between systems. We have to tools to make such testing reproducible but it’s underutilized. I want my tests to give me confidence. Unit tests don’t do nearly as good of a job as something that fully utilizes infra.

tippytippytango 4y ago

Exactly, if it made a big difference to profitability then it would be evident in the market place. TDD shops would out compete the ones that don’t use it. This doesn’t seem to happen in the market. What that means, if TDD is a benefit, it is such a small benefit that other factors in the business eclipse its impact.

agloeregrets 4y ago

> In theory, if TDD really reduces the number of bugs and speeds up development you would see if reflected in those higher level metrics that impact the customer. The issue is that many TDD diehards believe that bugs and delays are made by coders who did not properly qualify their code before they wrote it. In reality, bugs and delays are a product of an organization. Bad coders can write bad tests that pass bad code just fine. Overly short deadlines will cause poor tests. Furthermore, many coders reply that they have trouble with the task-switching nature of TDD. To write a complex function, I will probably break it out into a bunch of smaller pure functions. In TDD that may require you to either: 1. Write a larger function that passes the test and break it down. 2. Write a test that validates that the larger function calls other functions and then write tests that define each smaller function. The problem with these flows is that 1: Causes rework and 2 ends up being like reading a book out of order, you may get to function 3 and realize that function 2 needed additional data and now you have to rewrite your test for 2. Once again rework. I'm sure there are some gains in some spaces but overall it seems that the rework burns those gains off.

UK-Al05 4y ago
You shouldn't test those smaller functions. They're internal details. They should be private.
- iratewizard 4y ago
  You also shouldn't test business logic. Your test code is more likely to be a liability than an asset when it isn't testing your codebase's core infrastructure.
  - klysm 4y ago
    I totally agree with this. In practice, I see much more value in tests that fully utilize your dependencies. The hard part is tying all the shit together and not getting weird stuff on the boundaries between systems. We have to tools to make such testing reproducible but it’s underutilized. I want my tests to give me confidence. Unit tests don’t do nearly as good of a job as something that fully utilizes infra.