Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
olback11320340dFor 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.
netikras20867339dWell 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();
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 :)
but that's just my opinion
electrineer13159339dTDD 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.
electrineer13159339d@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.
swisspencilcase16339d@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).
deviloper2414339dI 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
deviloper2414338d@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