4 ms·

> Your design could change radically after creating the initial tests Which implies a cost of at least 2x in dev hours. One should always evaluate if it is wor

> Your design could change radically after creating the initial tests Which implies a cost of at least 2x in dev hours. One should always evaluate if it is worth double or triple LoCs to maintain.

deleted 2y ago
[deleted]
Jtsummers 2y ago
Why would it be double or triple the LoCs to maintain?
- 8n4vidtmkvmk 2y ago
  Vs zero tests? My tests are usually bigger than my implementation.
  - motorest 2y ago
    > Vs zero tests? If you don't bother with tests, discussing TDD is like famine victims discussing nutritional levels reported in food labels. > My tests are usually bigger than my implementation. That's perfectly fine if you feel your tests are important. Getting back to the topic, TDD does not enforce coverage targets or even minimum coverage bars.
- meiraleal 2y ago
  Because test is code, it has bugs, it needs refactoring, needs to update dependencies, creates technical debt just like the code it is testing. We could even create tests for the tests to be sure our test suíte works. It is just a tradeoff of speed and increased complexity.
motorest 2y ago
> Which implies a cost of at least 2x in dev hours. No, not really. I have no idea what led you to believe that. Think about this for a moment: does TDD force you to comply with a target coverage metric? Is the TDD police going to knock on your door if you leave out a usecases? What about a whole component? How many seconds does it cost you to add a test checking for the happy path?
- lucianbr 2y ago
  > does TDD force you to comply with a target coverage metric? Of course it does. You only write production code to make tests pass. Hence 100% coverage. When would any not-covered code be written in TDD?
  - motorest 2y ago
    > Of course it does. You only write production code to make tests pass. Hence 100% coverage. No, not really. TDD just requires red-green tests when adding features. You can add a test that only checks for the happy path. More to the point, nothing forces TDD practitioners to succumb to the hypothetical slippery slope fallacy of having to follow a fundamentalist path 100% of the time. Why do you believe that nonsense if even unit test best practices stay clear of 100% test coverages?
    - lucianbr 2y ago
      I mean if you do whatever you want and call it TDD, of course it doesn't restrict you in any way. But then any discussions about the properties of TDD are pointless. Anything you do is "just the right amount of TDD". Anyone who does less is "not doing TDD". Anyone who does more is a "fundamentalist dogmatic obsession-driven..." Yes, really.
      - motorest 2y ago
        > I mean if you do whatever you want and call it TDD (...) If you know what is TDD then you wouldn't make mistakes such as believing each and every single unit of code must have a test. That's specious reasoning and slippery slope sloppy thinking. > But then any discussions about the properties of TDD are pointless. Not really. You're just succumbing to slippery slope sloppy thinking. Adding a red test and working your way up to a green test is self explanatory. Being contrarian just wastes everyone's time.

> Your design could change radically after creating the initial tests Which implies a cost of at least 2x in dev hours. One should always evaluate if it is worth double or triple LoCs to maintain.

deleted 2y ago

[deleted]

Jtsummers 2y ago

Why would it be double or triple the LoCs to maintain?

8n4vidtmkvmk 2y ago
Vs zero tests? My tests are usually bigger than my implementation.
- motorest 2y ago
  > Vs zero tests? If you don't bother with tests, discussing TDD is like famine victims discussing nutritional levels reported in food labels. > My tests are usually bigger than my implementation. That's perfectly fine if you feel your tests are important. Getting back to the topic, TDD does not enforce coverage targets or even minimum coverage bars.
meiraleal 2y ago
Because test is code, it has bugs, it needs refactoring, needs to update dependencies, creates technical debt just like the code it is testing. We could even create tests for the tests to be sure our test suíte works. It is just a tradeoff of speed and increased complexity.

motorest 2y ago

> Which implies a cost of at least 2x in dev hours. No, not really. I have no idea what led you to believe that. Think about this for a moment: does TDD force you to comply with a target coverage metric? Is the TDD police going to knock on your door if you leave out a usecases? What about a whole component? How many seconds does it cost you to add a test checking for the happy path?

lucianbr 2y ago
> does TDD force you to comply with a target coverage metric? Of course it does. You only write production code to make tests pass. Hence 100% coverage. When would any not-covered code be written in TDD?
- motorest 2y ago
  > Of course it does. You only write production code to make tests pass. Hence 100% coverage. No, not really. TDD just requires red-green tests when adding features. You can add a test that only checks for the happy path. More to the point, nothing forces TDD practitioners to succumb to the hypothetical slippery slope fallacy of having to follow a fundamentalist path 100% of the time. Why do you believe that nonsense if even unit test best practices stay clear of 100% test coverages?
  - lucianbr 2y ago
    I mean if you do whatever you want and call it TDD, of course it doesn't restrict you in any way. But then any discussions about the properties of TDD are pointless. Anything you do is "just the right amount of TDD". Anyone who does less is "not doing TDD". Anyone who does more is a "fundamentalist dogmatic obsession-driven..." Yes, really.
    - motorest 2y ago
      > I mean if you do whatever you want and call it TDD (...) If you know what is TDD then you wouldn't make mistakes such as believing each and every single unit of code must have a test. That's specious reasoning and slippery slope sloppy thinking. > But then any discussions about the properties of TDD are pointless. Not really. You're just succumbing to slippery slope sloppy thinking. Adding a red test and working your way up to a green test is self explanatory. Being contrarian just wastes everyone's time.