Re:When I do TDD and when I don’t
by leemcalilly on Thursday February 17, 2022 @03:55PM
(#30378535)
I find my system/integration tests to be the most valuable because those test the behavior of my code, what the end user cares about.
It often helps to start with the design first (even if just a napkin sketch). Once I’ve done that I usually have enough information to write system tests (which also forces me to consider edge cases). Then I can then fill in with unit tests as needed as I write the code to get the system tests for that feature passing.
Re:When I do TDD and when I don’t
by jasonswett on Thursday February 17, 2022 @03:37PM
(#30378342)
I personally don't see any reason why the type of test matters when doing TDD. As I see it you can do TDD with integration tests just as much as you can do TDD with unit tests. The only difference to me is that the work involved might take on a bit of a different character. But that doesn't make it not TDD to me.
I've found TDD can work pretty well with integration tests. Often better.
I dont really get why the practise is so intrinsically linked to the practise of writing unit tests.
Increasingly I'm starting to believe unit tests are a scam, but TDD is going to stick around in one form of another forever.
Re:When I do TDD and when I don’t
by markmaglana on Saturday February 19, 2022 @04:18AM
(#30395633)
JB Rainsberger would like a word with you :-)
https://blog.thecodewhisperer.com/permalink/integrated-tests...
I was actually surprised what the author was describing was somehow _not_ TDD. I thought it was pretty normal to try some things out, make some decisions, and then return to codifying those decisions in tests.
We do web app development, and 90% of our tests are browser-based integration tests that test whether the given inputs (usually forms) lead to the expected outputs (usually something printed on a web page).
I wonder if this is more natural when you're mostly writing integration tests?