[sagolikasoppor]

Oh man. You can write tests after the fact. I have done it sucessfully many times. I write something to see if its viable, if it is I find the repetitive parts and break them up to functions or components in which you can unit test. Later you can also write end to end tests for all the important flows.

TDD is just a way of doing things but it's not faster. It's testing for testings sake. Why should I write a test if I don't have a single paying customer yet? Unless its something massively important, like money or health data there is just little incentives.

[hitchstory]

If you do test-after you have to keep a mental tally of new scenarios to test when making code changes. This makes it more unreliable since it's easy to forget one of those scenarios or mix it up with an already tested scenario.

TDD lets you safely forget by tying the test pass/failure directly to the code.

So, yes, you can do test-after but why?

The only reason Ive ever heard for doing it after anyway is "I just prefer it that way".

Not writing tests at all makes sense (e.g. for a spike), but if I were going to start writing tests at any point I cant see any reason not to do it with TDD.

[cgopalan]

My experience is that TDD just ensures that the code is unit-testable. This can lead to more complex code when it need not be complex. I definitely write tests, but my default approach is to make the test simulate how a user would use the functionality. So mostly a higher level test like a system test. And you can do this only when you have a bigger picture of the program that you write (which need not be driven by unit tests, just need to elucidate what the program needs to do and break it into steps). I don't rule out unit tests, but my approach is to start with tests that resemble system tests, and if i specifically need a unit test for a hairy algorithm in a function, use a unit test to help.

Also the higher level you test at, the less probable that you have to change the tests when you change a piece of functionality.

[hitchstory]

It's called TDD not UTDD.

I frequently do TDD with integration and end to end tests. The type of test should be dictated by the nature of the code, which TDD doesnt have an opinion on.

TDD is about following red-green-refactor.

[cgopalan]

Good for you then. I myself have not come across the (loud/louder) TDD exponents advocating for using TDD in system/integration testing, they mostly focus on unit tests. If you can point to some examples, it would be a learning experience for me. If not that's fine too, I am glad that there are voices out there like yours.

[hitchstory]

I wrote a systems/integration testing framework for this purpose specifically and I wrote a few essays alongside it. It has the same name as my handle.

Not much traction, unfortunately. Id be interested in any comments you might have.

[ChrisMarshallNY]

I write tests alongside the code. I also write tests before the code, and after the code.

Usually, I use test harnesses[0]. These generally start before the code, and grow, alongside.

I’ll frequently write unit tests, after the code is done. Sort of like putting solder over a tightened bolt.

But I tend to spend a lot of time and effort on testing. It’s my experience, that I always find issues. I’ve never once, written “perfect” code, out of the starting gate.

Eh. WFM. YMMV.

IRT the post topic, I believe that every job I do -even “farting around” code- needs to be done as well as possible. If I always do a good job, then it becomes habit.

[0] https://littlegreenviper.com/testing-harness-vs-unit/

[rchaves]

I’ve seen people spending 10 minutes to test things by hand, would have taken them less to write and run a test, specially with AI now

When writing test actually makes it faster to code, THEN it’s worth it. You can even throw the tests away later, doesn’t matter