3 ms·

The Big TDD Misunderstanding

8 points by WolfOliver 5y ago

jdlshore 5y ago
Kind of a weird article, TBH. I’m not sure where he got the opening idea that “unit” refers to the test rather than the unit under test. Similarly, I can’t agree that it’s okay to e2e test. I need my tests to be fast and reliable, and e2e tests… aren’t. They’re also a pain to set up. I’m a dyed-in-the-wool classicist, as the author says he is, but what he’s describing isn’t what I’d call a classicist approach.
- olliej 5y ago
  I agree on this article being weird. As to your other comments your e2e tests are not reliable there’s an issue with your test harness/infrastructure. The length of time your tests take to run obviously shouldn’t be too long, but if you have tests for every change your testing must by definition take longer as time goes by. Failing to have e2e tests also mean you miss unexpected interactions. For a complex system testing a single thing in isolation is seldom useful. If you look at some of the heavily tested projects like the browser engines, llvm, etc there are few (if any) “unit tests” because fundamentally it’s not useful. Tests for css layout or for IR generation make no sense without the rest of the code around them running. LLVM has semi-regular bugs in optimization that occur when different optimization passes are use together. A purely unit test driven approach to system testing does not work effectively once you get much bigger than than a single dev product.
  - jdlshore 5y ago
    Depends on what you mean by unit tests. A lot of people mean solitary, interaction-based tests. However, the classicist approach is to have sociable, state-based tests, and those lead to great results. I have an article about this that’s gotten a lot of love—I’m on my phone at the moment, but a web search for “testing without mocks james shore” will find it.
  - WolfOliver 5y ago
    I added some sources for the the unit tests thing and also rewrote the point with the e2e test to describe it better.

8 points by WolfOliver 5y ago

Kind of a weird article, TBH. I’m not sure where he got the opening idea that “unit” refers to the test rather than the unit under test. Similarly, I can’t agree that it’s okay to e2e test. I need my tests to be fast and reliable, and e2e tests… aren’t. They’re also a pain to set up. I’m a dyed-in-the-wool classicist, as the author says he is, but what he’s describing isn’t what I’d call a classicist approach.

olliej 5y ago
I agree on this article being weird. As to your other comments your e2e tests are not reliable there’s an issue with your test harness/infrastructure. The length of time your tests take to run obviously shouldn’t be too long, but if you have tests for every change your testing must by definition take longer as time goes by. Failing to have e2e tests also mean you miss unexpected interactions. For a complex system testing a single thing in isolation is seldom useful. If you look at some of the heavily tested projects like the browser engines, llvm, etc there are few (if any) “unit tests” because fundamentally it’s not useful. Tests for css layout or for IR generation make no sense without the rest of the code around them running. LLVM has semi-regular bugs in optimization that occur when different optimization passes are use together. A purely unit test driven approach to system testing does not work effectively once you get much bigger than than a single dev product.
- jdlshore 5y ago
  Depends on what you mean by unit tests. A lot of people mean solitary, interaction-based tests. However, the classicist approach is to have sociable, state-based tests, and those lead to great results. I have an article about this that’s gotten a lot of love—I’m on my phone at the moment, but a web search for “testing without mocks james shore” will find it.
- WolfOliver 5y ago
  I added some sources for the the unit tests thing and also rewrote the point with the e2e test to describe it better.