[lamontcg]

I'm not sure if I go even further or not, but I'm perfectly happy to write code first and then write tests. And I will sometimes not write tests until I start debugging code and start thinking to myself "is it a buggy bit of this function I haven't tested yet?" and so I'll write the test to prove it isn't that bit.

With code I'm getting paid for I'll write more tests up front and won't skip that step, but for code I'm playing with then as long as I'm just enjoying myself writing code I'll write zero tests for awhile and just code. Then as I hit the debugging/refactoring step I'll do the backfilling as a form of debugging. Often I'll write the code that fixes the bug, then write the test, then quickly and temporarily revert just the code to ensure that the tests fail and then proceed. That gets you the same safety check as doing it the test-driven way to validate your test actually tested the right thing.

I really tend to hate "thou shalt start by writing tests" as some kind of immutable golden rule. It does always feel good to me when I just naturally wind up doing it, but forcing myself to do it every single time just isn't any fun at all.

At the same time tests are absolutely essential when it comes to refactoring and debugging. When you get too far out ahead of yourself with code then you start needing to shore up the foundations and use tests to eliminate bugs in the code that you've already written. Some code though is obviously correct enough that in personal hobby projects I won't ever code tests for them (unless I do hit the point where I start to doubt their correctness due to some funny bug at which point the situation has changed so I add some tests to prove it one way or the other).

The whole point of this though is that the tests are always serving me and they aren't in the drivers seat quite the way that all the TDD 101 blog posts like to ram down your throat and which I suspect turns people off from that approach so much.

The end result is also that you'll tend to wind up with the tests that are actually useful, covering the code that is particularly hairy or essential and the edge conditions that you really need to make sure to get correct, and you wind up having a test suite which is composed mostly of useful tests instead of all the largely useless ones that infect codebases.

I'll also happily omit tests on lower level functions that are well tested at the level above them, because I don't need to test the same thing at 18 different levels (again, for professional use I'm more likely to include tests at every level if they're fairly mechanical to produce). I also have a flexible definition of what the system under test is, which often encompasses more than just the immediate object that I'm testing and I don't bother wasting mental effort thinking about how to mock the whole world.

I don't know what kind of TXX that is. I still wind up with tests, they're legitimately essential to have, I just don't get there via some prescriptive route. I wind up with good code coverage, but I don't necessarily wind up with it looking as comprehensive as rotely banging out lots of unit test. I typically wind up with tests that I know are useful because they were produced by hitting actual bugs or where I had real questions about the behavior of the code and needed to assert some invariants and prove the code worked.

[Jtsummers]

An important element of TDD is that it wasn't supposed to be prescriptive. It's a tool/technique to use. Sensible people know when to use it and when not to. Even Beck (who many here and elsewhere assume is dogmatic about TDD) has said on many occasions he doesn't use it 100% of the time and wouldn't use it 100% of the time.

[nonethewiser]

Does test driven mean you need to write the test first? Seems pretty clear to me. I dont think testing needs to be so dogmatic but TDD kinda is.

[Jtsummers]

That's not dogma, that's the technique. If you aren't writing the test first then you aren't doing TDD, and that's fine. There's nothing wrong with not doing TDD at all if that's what you choose.

The dogma most people see or claim to see is that TDD is meant to be used everywhere (or nearly). Which some fools, yes, believe. But they're just that, fools. People who use their brains (aka, non-fools) know them to be fools and do what works for them and the circumstances because they spend some time thinking about things instead of parroting a dogma (or an anti-dogma).

[hbrn]

> The dogma most people see or claim to see is that TDD is meant to be used everywhere

And yet TDD preachers are never drawing the boundaries for TDD applicability. They are always extremely vague: "sometimes I see that TDD doesn't work for the problem that I'm solving and I don't use it". Well, how do you see it? What types of problems is it bad for?

If TDD works, they take credit. If it doesn't work, "it's just a tool" or "you used it wrong".

It is literally impossible to prove that TDD doesn't work. Which makes it a religion.

[lamontcg]

The "fools" are writing most of the blog posts on TDD.

At some point the No True Scotsman fallacy kicks in pretty hard and that is just what TDD actually is.

[bcrosby95]

Dogma tends to be a sign of an intermediate experienced developer.

[bloat]

If you're doing TDD then yes, you're writing the tests first. But even Kent Beck says you don't need to do TDD all the time. So where's the dogmatism?

[hitchstory]

Unfortunately Uncle Bob used to preach 100% usage and IIRC Beck never really specified when it should be used.

[Jtsummers]

I mean, how can he? You're the one that knows your system so you have to be the judge on whether TDD is appropriate or not for it, or for parts of it. He says as much in his talks on TDD and in his book. You have a brain, use it, don't expect him to think for you on systems he has no knowledge of.

[Izkata]

Pretty much the same for me: I'm only able to write any sort of decent tests if there's some initial version of the code already there. Typically that means a prototype-ish only-works-on-the-happy-path version I wrote in an exploratory way, then that first test can be for the happy path. After that it's pretty easy to copy the test, tweak parameters, and figure out where the first version breaks TDD-style.

[naasking]

> I really tend to hate "thou shalt start by writing tests" as some kind of immutable golden rule

The only study I've seen on this shows only tests were correlated with more correct programs, but doing tests first or last showed no significant difference.