TDD.

I'm a fan of writing tests right after you write every module. I actually think it's doable.

But I'm not a big fan of traditional TDD, which is defined as: first writing the tests, making them fail, writing code until tests don't fail.

My experience with traditional TDD when writing library code is that you start with this very naive idea of what is needed, so you write classes and functions and a lot of times they look like overly simplistic pseudocode.

So what do you do? You scratch that, you delete those classes/functions several times.

I think this discovery process that your code is naive is slowed the fuck down by doing TDD.

I'd rather write a theoretical API in a readme file, then write code, and then write the tests, you can even withhold writing the tests, but never leaving them for another day, just so that you don't waste time writing tests that you're going to scratch.

There's always a time constraint, and most of us can't afford bikeshedding.

Traditional TDD feels like an esoteric thing, it tries to make programming a series of steps, it actually sounds like an infommercial.
"FOLLOW THESE 3 SIMPLE STEPS AND WRITE THE BEST CODE EVER"

For my final school project I wrote the API documentation with OpenAPI before writing any code. The structure was all done before I started writing any code. This allowed me to really focus on the code and not worry about having to rewrite anything later.

@olback right, it's very sensible. I guess DDD, right?

Well idk, maybe it's a matter of personal POV... But I liked that tdd idea very much. I did write a few modules using pure tdd, and they are now rock solid.

Imo writing tests AFTER the production code is written is not reliable. I mean you already know your code is working, you've alreadu tested most of the possible flows. You're no longer motivated to keep covering your codebase with excessive and corner-case tests.

This dilemma is not the case for tdd. Tdd makes you think of what cases your code has to cover next. Too long input? Proper input? Input w/ invalid bytes? No input? You do cover it all and make your code bulletproof.

I like many things tdd can offer. But most of all -
1. Your code has perfect coverage, so you can refactor/optimize it freely w/o risking to create bugs
2. You have perfect documentation for your code. E.G.

public void userInput_TooLong_ShouldThrowInvalidArgExc();
integrationGmaps_ResponseTookTooLong_ShouldThrowTimeoutExc();

and so on. Should a new business rule appear -- write a new test with a name describing it and implement the rule. If you make a hotfix to fix a bug in prod you will know which use cases might malfunction as a result.

I mean.. There's no way you'll cover all tge components' use-cases after you already have the code done... They're already in confluence and they are so obvious - it'd seem like a waste of time :)

we're lazy

but that's just my opinion

TDD requires you to know what you are doing beforehand.

@netikras yeah, I'm not against test driven development in general, I'm against the traditional "trademarked" tdd, which feels too restrictive or equates a developer to a useless person.

I agree that writing tests after code is running in production tends to result in low code cov.
I meant to say that you can write the tests as you write code or immediately after.

If I think about my last project, I think at some points I actually wrote the tests before the code, but it wasn't like a hard rule that I had to follow, which is how it feels when many people talk about tdd.

@SHA-16384 not really. As op described, you can also start with some initial idea and change it if you find out that it would not work or if something else would be better.

@erandria I don't think @olback is not necessarily describing DDD. He is simply saying that he defines the public APIs first. Those are just public interfaces. If you are able do that, there should be no issues writing the tests beforehand since you know the interfaces are already fixed (unless they're not).

@swisspencilcase you're right, thanks for the clarification.

I interpreted it as if he first wrote docs for the methods, not that he actually coded them. Sounds like a very good idea.

I do TDD cycle for pleasure. I feel happy and satisfied when, slowly, step by step, all tests start to become green.
I hit the "run tests" button very often, sometimes even after few line changes.
It also help me understand what I need to do.
I also write tests as a way of telling other what to do.

I would embrace this way totally if only didn't have a huge legacy on my back

@deviloper wow, writing tests for others must be a very enjoyable thing.

@erandria it's easier and faster than explaining a complex functional thing.
Here it's the test, work and pass it, don't come back until it's green...If really I could live up to this philosophy, my life would be much easier.

In addition tests contains the "Business Rules" the only thing I would care about