this post was submitted on 10 Dec 2024
7 points (100.0% liked)
Hacker News
322 readers
235 users here now
RSS Feed of HackerNews
founded 3 months ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I generally agree, though I think the author misses out on what IMO is the most important part of TDD - the red/green/refactor loop. I think this is one of the most important parts that people just gloss over or don't implement correctly yet the most valuable part of what TDD teaches you.
Personally I try to stick to this as much as you can - shorter feedback loops is vital for coding things quickly and with fewer issues. But to me tests are more of a loose concept and vary (in similar ways that OP describes) how I implement them. Could be anything from a fully fledged test as TTD describes, or maybe just that the code runs and produces the expected output or even just that it compiles correctly.
All depends on what exactly I am doing. If I am doing maintenance on a project I am much more likely to write fully fledged tests, but if I am writing a one off script that needs to batch process data I am far more likely to just run it on a subset of data and eyeball the output. There is little point in wasting a bunch of time writing tests for a one-off process. Or if I am making styling changes to a UI I will just build/run it in the background and refresh the web page to see if what I have changed is better or not.
But the red/green/refactor loop is equally important in all most all situations. I really don't understand how people can write a non trivial function, or test or even whole class without ever even compiling, let alone running, their code. Far better to get feedback on what you have written as soon as you can, even if that feedback is just it still compiles. And fix things as soon as you break them.
You can do this loop and write tests, or partial tests, before, after or even manually check things between each step. And manual checking does not have to be a laborious process - if it is then you should be writing tests. Sometimes I even write a test that asserts nothing but just runs the code and prints the output so I can manually inspect it - which is great when you are in a more exploratory phase and don't quite know what you want yet. Doing this can often lead to a full test case later on and other times I just delete it after I am done.