Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
This sounds like an explanation that most beginners of unit tests would love to hear
korrat5432yAddendum: Adding tests later is only faster if you add none at all
TDD is the way to go. I think even if you write tests after you could easily get into a trap of validating your assumptions about the code you just wrote instead of making sure your code passes all of the tests you wrote prior to coding.
Also, the number of times I have had to explain how to know what your 'unit' is is ridiculous.
Doing something new in a language you don't fully understand yet is not something to be done witb TDD.
You can tell me whatever you want, but in that case: screw you!
@wildebeest TDD is not for solving bugs. Bugs still happen as developers forget about egde cases (I still do).
Yet a lot of bugs also are unclear requirements that yet have to be made explicit. (The classic "that's not a bug report but a feature request".)
Think of test-code as a living and evolving documentation of your business code giving you almost instant feedback if something breaks.
That's why if you detect a bug (or business requirement changes), you add a test case for it first in order to fail the test. Then you make it pass again.
TDD is about preventing regressions first due to refactoring and knowing you have a working state.
@wildebeest When learning a new language, I always learn the test framework first ¯\_(ツ)_/¯
And in regards to acceptance tests, I have implemented a super booking API that abstracts away a lot of third party API. For each third party API and each of our endpoint we have at least one acceptance test, yet often more as there are loads of edge cases.
Acceptance tests are good at telling you that something broke, but really really bad in telling what exactly went wrong and why.
On the other hand acceptance test can really save you on code bases without unit tests.
Once, I inherited a project without any tests. My first action was creating an acceptance test for it. Then at least I knew I broke stuff. Yet I also slowly and over time added unit test cases for the project, as I rather deal with a breaking unit than acceptance test.
For critical parts of your application acceptance test make sense, yet unit tests should be your first line of defense. (Look up "test pyramid")