Hacker News Reader

Comment by x86x87 | Hacker News Reader

I think we all do a bit of TDD, just not the extreme kind. If you already have the code and now you're trying to extend it, thinking about how this is going to be done and writing a few tests around the usage makes sense. It also makes sense if you don't have the code but you do have a way to structure the code in your mind and you can figure out what parts you can build and test first.

So while it's not TDD in the pure sense (it's more like Test Assisted Development) it is leveraging the spirit of TDD.

View on HN

TAD has just about the right sound, too. I've found it's a useful tool for very specific tasks. I found TDD perfect for writing functions or modules with a wide variety of possible state-dependent outputs. While not strictly TDD, I've also found it helpful to sit down and frame a list of desired behaviors for a piece of code as expectations first, then go through the process of writing the code and tests in tandem. It's nice when you know exactly what you need to do, but not how to do it. It's much less helpful when you know the how but not exactly what.

Yeah. To me it's about not being a zealot about it. If I can get 80% of the value with 20% of the effortby tweaking it I think that makes sense.

"Just a TAD is all you need."

https://www.merriam-webster.com/dictionary/tad

Could have been worse. Could have gotten: https://www.urbandictionary.com/define.php?term=Tad

Hmm... Wait. Is that worse?

In a sense, even the way I use print statements and other outputs to validate the behavior of a non-TDD program at each iteration could be called test assisted or something. It's just in that case, the test is the whole program at each iteration, rather than something that is fully automated and decoupled from its normal operation. Each test then expands in scope with the scope of the program, not being preserved except perhaps as assertions or log messages.

Sort of. The way i'm thinkjng about it is that you do write the tests and the final output would resemble what you woukd get with TDD, it's just that you put a little more thought into the structure of your software before starting to write the tests

I get what you mean. I was stretching the idea a lot. What I described might be more aptly called "iterative development", and is really basic. There is an even further extreme than that from TDD, though. It's of course possible to write a program without even ephemeral, manual tests, just intuiting how it will work as you build it instead of checking and iterating... but anyone with experience knows better than to try that beyond trivial programs.

Yes. I have a name for your method also: debugger free development (DFD!). While controversial with some my theory is that if you need to attach a debugger to understand what is going on with a live program you've already lost. Logging (ie printf++) and metrics should allow you to understand what happens at all times. You may need to adjust the log level but that's about it.

Reply on news.ycombinator.com