[HN Gopher] The Big TDD Misunderstanding (2022)
___________________________________________________________________
The Big TDD Misunderstanding (2022)
Author : WolfOliver
Score : 24 points
Date : 2025-02-15 18:08 UTC (4 hours ago)
(HTM) web link (linkedrecords.com)
(TXT) w3m dump (linkedrecords.com)
| brumar wrote:
| > Do not isolate code when you test it.
|
| > Only isolate your code from truly external services
|
| That makes tests more trustworthy but also sometimes harder to
| maintain I think. I have seen cases where small changes on the
| code base created strong ripple effects with many tests to
| update. Arguably, the tests were not very well written or
| organized and with too many high level tests. Still, this and the
| very large execution time of the test collection made me realized
| that for medium to large projects, I will be much more careful in
| the future before going all in with the no-mock approach.
| nobleach wrote:
| Or, write code that _can_ work in isolation. (Pure functions).
| You can bet when GM builds fuel injectors, they have a harness
| that they can place them in to make sure that JUST the injector
| gets tested... putting it in a car and driving around is the
| wrong approach.
|
| The same is often true for software. Ensuring that things
| integrate is vital. Ensuring that functions run in isolation
| also has value.
| battered8310 wrote:
| Absolutely, whenever there is hardware in the loop, the more
| of the system you test with the more expensive the test is
| and the harder it is to isolate issues.
|
| That's not to say you can skip end to end testing, but the
| more testing pushed to the complete system level will drive
| up cost and schedule.
| recursivedoubts wrote:
| Agree w/the author that the concept of "unit" often hurts test
| quality.
|
| You should be striving to balance the long-term usefulness of
| your tests with the debuggability of those tests. In my
| experience, those tests are what most people would call
| "integration tests" (although that name, like so much terminology
| in the testing world, is confusing and poorly defined.)
|
| You want to get the tests up at as high a level of abstraction as
| possible where the API and correctness assertions are likely to
| survive implementation detail changes (unlike many unit tests)
| while at the same time avoiding the opaque and difficult to debug
| errors that come with end-to-end testing (again, the language
| here is confusing, I assume you know what I mean.)
|
| See https://grugbrain.dev/#grug-on-testing
| nobleach wrote:
| Eh, I knew this would somehow come back to that Kent C Dodds
| stuff. I can respect the guy, but his opinion on valuable testing
| differs from mine and quite a lot of others. His opinion is "the
| more your tests represent the way your users use your app, the
| better they are". For E2E tests, yes, absolutely. For unit tests,
| no... not at all. As a very short example, an E2E test will prove
| that yes, I did indeed show a button on the screen. A unit test
| will prove the code that put it there worked. The code can "fail
| open" for many reasons. (In JavaScript for example, forgetting an
| `await` keyword can return a truthy value!).
|
| The worst part about it is that he called himself a thought
| leader, called his approach a "best practice" and had nothing
| really to back that up. Now people go around repeating it all the
| time. It's frustrating.
| 9rx wrote:
| That's not in line with the original definition of unit test.
| It also sounds like a pointless test using your definition.
| There is no advocacy for writing pointless tests.
| int_19h wrote:
| If you have an E2E test that tests the button behavior
| thoroughly (i.e. not just showing it, but the fact that, when
| it's clicked, the app state changes accordingly), then you have
| a test showing that "code that put it there worked".
| jbreckmckye wrote:
| Kent Dodds is an unusual character. I wouldn't say he is a
| charlatan but he's not a highly experienced developer. He spent
| a few years at PayPal but most of his career has been a
| "developer educator".
| int_19h wrote:
| Simple rule of thumb.
|
| Always write functional tests first. Doesn't matter if they are
| slow - you still want something that faithfully captures the
| specified behavior and allows you to detect regressions
| automatically.
|
| Then, _if_ your resulting test suite is too slow, add finer-
| grained tests in areas where the perf benefits of doing so dwarf
| the cost of necessary black-boxing.
|
| Getting down to the level of individual classes, never mind
| functions - i.e. the traditional "unit tests" - should be fairly
| rare in non-library code.
___________________________________________________________________
(page generated 2025-02-15 23:00 UTC)