Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
Do it 100% with the rules first, rhem start experimenting and then make your own rules
The most important thing I got from tdd is how to write testable code
notoriousmonk3913dI think it's important to learn how to test properly, so you can create easily testable code from the beginning, which makes your code much cleaner in general. Doing tdd on a project might help learning that quickly. But still I'm also lazy, so yeah I write tests afterwards, usually when I'm procrastinating writing "real" code and don't want to feel unproductive. I'd call it test oriented programming. For me that's a good compromise between my perfectionism and my lazyness.
Root7263113d@alexbrooklyn @notoriousmonk Yes.
Try TDD as intended first. Then change it to fit you.
Most devs will Learn to write testable code, and start writing their tests after (plus refactoring as needed)
I often find myself doing both. Sometimes I have an idea for a test while I’m building a feature and want to write it before I forget, or write tests during because I’m about to refactor something and want to ensure it both works as-is and that my pending changes won’t break the behavior.
C0D46223613dWhat others have said.
You start at tests first, but then management gets in the way. Either w deadline gets shrunk to shit or a project pivots so hard you are glad you didn't write those tests in the first place, nothing like writing ~140 tests just to have things pivot and you end up throwing them all in the trash.
So you end up with tests after implementation to ensure any future work doesn't introduce breaking changes (unless deliberate)
Learn to write clean, well planned, testable code, and you won't need to
have a test waiting for you to prove it works, you should be able to read the code and determine what goes in, and what comes out without running it.
Tests just enforce that what your code does now, will continue to do so later when something is changed.
junon263213dBasically what @Root said though I tend to be conservative about writing tests first. Usually I sit down and do one feature at a time, which includes both the code and the test.
As she said, sometimes there's a feature I want and will write a test for it first just so I don't forget. I like to place "markers" in my code to force me to look at places again in the future.
Fast-Nop3203113dI think TDD is dubious. The design shouldn't be driven by tests, but by business requirements - which in turn also should drive the tests.
Also, you're no less likely to have bugs in the test code than in the actual code. Actually even more because exhaustive testing code dwarfs the production code, given the state space.
So you can't test exhaustively anyway and have to choose - but based on what? By suddenly taking the smart pill when writing the test cases? Why not just taking that pill when writing the business code?
It's more likely that you don't take the smart pill in either case and have the same misunderstandings in both business and test code, which is why the tests shouldn't be written by the same dev in the first place.
About the only advantage I see is that the TDD order makes sure that there is any test code at all instead of just cutting down on the verification phase when the release date approaches. But that points to a process deficiency with QA lacking power.
Lucky-Loek31913dI think TDD is pretty helpful in my master, where I'm constantly writing pretty hard code in languages I don't know. I can define what I expect the code to be doing up front and then continue to pull my hair out over the next few days while writing incomprehensible one liners and structures. Once the test succeeds, I can fairly easily refactor to code that's actually readable.
Also this vid (probably recycled from others but whatever) opened my eyes on what TDD is really about and why it is helpful: https://youtu.be/EZ05e7EMOLM TL;DR a "unit" is not a method but a behavior. Test behaviors, not methods.
I find it valuable to write tests first, as it gives me time to properly think things through, and insight into what I'm really doing.
Especially for larger implementations.
It's also very valuable to be able to quickly get an overview from test stories.
For documentation, I very often just rephrase my tests into a document 😊
hjk101290812dI don't do TDD but I almost always make my test be the codes first user. That gives a bit more freedom but still makes sure there is test and it's easy to debug the plumbing.