Test-driven development

Over the years I have found companies mix up tdd and the general idea of tests.
Everyone I've ever met has a better experience developing then creating tests.
TDD is a great development method for fizzbuzz level applications

writing tests isnt that useful. writing good design docs is though.

Maybe if your creating apps. But if your releasing libraries or system critical code tests need to be made and starting with them forces the developers to think of how their implementing their code.

Adding, its often 2 different people or even teams. One writes writes the tests and the other the code as to check your work.

>How do I know what test cases should I generate?
by knowing what business logic you're about to implement, i.e. not "lel whatever brainfart comes out"

>How do I know I've written enough test cases?
if it covers all use cases

tdd only works for certain things, like boring rest apis or smart contracts.

building an app for example has barely any need for

Writing tests just means you are a bad programmer. If you are a bad programmer, you will also be bad at writing tests and there will always be things your tests can't detect. Write code, not tests.

you mean not writing tests means ur a bad programmer.

>people in the 2000s actually fell for this meme

Attached: 1300044776986.jpg (600x600, 35K)

programming is just a pile of memes

Stop misleading the retards on this board

Attached: 1559834916811.jpg (665x786, 100K)

Because you should spend 90% of the time planning, writing documentation and comunicating, and only after that you start writing code, and by then you know what tests you need. Only web codemonkeys jump straight to writing code without even having a good idea of what are they trying to achieve in the end. It's so dumb it's surreal, that's why the entirety of web is so shit.

fpbp

Okay but what about TDD

your test cases should be directly related to the spec you get from the suits based on the design docs, that is, when all your tests pass you should hit 100% of design spec. if you get no spec, you can't use TD. can still write tests though, and in that case you should focus on validity over expected input set and edge cases i guess?

It only works for E N T E R P R I S E projects where "software architects" fully wrote out the API and detailed rules for error handling. If you're working alone and trying to make something new, you're going to be doing a lot of exploratory coding, improvising multiple versions of one feature before settling. TDD doesn't work at all for this.

So you need SDLC/Agile? That's way too much work for one person.

(You)

You write one test for each logic bifurcation, its simple as that.
You have a method that can return valid A, B or C given some set of conditions or raise D or E expected exceptions given the absence/corruption of some other set of conditions, so you MUST test for A, B, C,D and E and rinse repeat throughout your code.
TDD is so important because subjecting your program though this level of coverage is usually an extremely annoying and lengthy monkey job unless you you do it organically in development time and not afterwards

>you should spend 90% of your time not writing code

Yikes

You suffer from enterprise bureaucracy Stockholm syndrome if you think that is normal

You probably work on a large team where a 100 line weekly diff is acceptable. That doesn't get shit done in a small company

>t. Worked at behemoths and tiny startups