Here's what Eric Elliot (one of the famous JS developers) wrote recently on TTD:

What happens if you don’t want / like / can’t use TDD?

40% — 80% more bugs in production.

What happens if you don’t want / like / can’t have other people reviewing your code?

33 hours of extra maintenance for every hour that would have been spent on code review (note: the studies these numbers are pulled from used static types.) Basically, skipping TDD and code review is a ridiculously bad idea — even if you use static types.

It is well accepted that types make a software more robust.

Define “more robust”. If you mean fewer bugs, it may be true that’s the popular consensus, but it’s not based on any real evidence that I’m aware of. A lot of people once believed the world was flat, too.

True, that you can try to accomplish robustness through other means besides types. TDD, code review, x, y, z, etc.

Yeah, but there’s some good evidence to support those bug-reducing methods… not so with static types.

I have been doing it for a long time and it has proven itself to make my code more robust (without TDD and code reviews).

I absolutely believe that you feel like static types help you write better code. I felt that way, too! Static types provide a very effective Linus blanket. They make us feel better, but static types don’t reduce bugs by much.

View full conversation here: medium.com/@_ericelliott/40-80-more-bugs-in-produ…

While (automated) testing is essential, whether or not to write tests first, depends on the problem being solved.

If the problem being solved is precisely specified then TDD makes perfect sense. Even more so if you can convince your clients/decision makers to write them for you (gherkin based acceptance tests). In these cases writing tests before/after does not result in any difference in time undertaken in the long run, and writing code against a spec can help you catch bugs early.

Even if you defer the actual automated verification of cucumber specs to a later stage, having the spec in front of you can help organize and prioritize your work, as you have a granular checklist.

Another area where TDD makes perfect sense is when you are introducing small well defined modifications in a large/complex enterprise system.

However TDD is not suitable for cases involving exploratory programming. In these use-cases your problem is almost always not well defined. You may have some dataset and you may want to explore different facets of it in a jupyter notebook, or try to fit different models to it. Or maybe you want to visualize the dataset in different ways to figure out which one conveys the meaning best. Similarly, you may have some APIs but you are just exploring if they can be integrated together. For these use cases it is almost always better to write tests later as a safeguard against future regressions.

Also in strongly typed languages like F#, OCaml, Haskell etc. you can model much of your domains constraints through type relations. Experts in this approach can model types to fit the domain to such an extent that if the code compiles then it is almost guaranteed to be correct because reliance on run time checks is minimized. Conventional test cases are required only as a secondary measure, and for things can not be checked by compiler - so can be written later.

Definitively not ! More you've write tests, less QA or users bad results/returns you've got, and it's fit very well with all workflows. In my mind of course :)

Not doing it when you can is the bigger waste.

TDD helps cover not just making sure your code works, but when done well can also cover other needs:

• if you write your tests first, gives you a better sense of your progress and how much is remaining (e.g. you have 20/40 tests written and passing)
• it gives future developers an example of how your code actually works with an actual example, not just documentation on "how it should be used"
• this one's obvious, but it also gives future developers some assurances they didn't just break your code with a new feature or bugfix (this assumes you wrote your tests well, of course)
• it can help increase your confidence in your code, and reduce stress in your mind about things you might have missed.. if you think you missed something, write a test, prove your code works -- even if it's just to prove to yourself, it's worth it

TDD is a trade-off: it slows you done in the now but it saves you time in the future. I'm not a TDD guy I am a DDT Guy -> development driven testing guy.

I write my components / modules (prototypes) and than I write test to improve them. -> first i build it, than i test the "expected" cases and than i think about it outside of the integrated context and try to break it (generative testing).

every function or class has to be as deterministic as possible (I ignore language implementation flaws).

which is reduction of side effects, in turn it is usefully to reduce cyclomatic complexity , as well as other complexities (for example scalar parameter instead of objects if possible) -> which just means reduce the amount of possible different results/behaviours of a function/method/class and reduction of dependencies of it.

explaining this in detail .... would lead to far .... in general TDD is a good thing like almost all architectural approaches ....

.... if you never did TDD I highly recommend it because it lets you reflect upon your implementation. If you find out that it imperes your productivity to much you could define core functionalities that need to have a certain coverage and others with lesser coverage to keep a balance between time spent on implementing and time spent on writing / refactoring tests.

Algorithms have to be unit tested.

Everything else is biased... by network problems, data inconsistency, unexpected user behavior, platform dependent features, unit test obsolescence.

Truth is the developer will always try to test what he/she thinks should be working and turns unit tests into a discard argument and an excuse for misconceptions.

Source

Over the years I have come to describe Test Driven Development in terms of three simple rules. They are:

1. You are not allowed to write any production code unless it is to make a failing unit test pass.
2. You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test.

You have to think about it, but it makes sense. TDD is not always required but it is always advised, even if you don't use it in your day-to-day work you should at least understand how it works and try it a few times/examples.

I think it's not a waste, because if you first make the test and after the programming, you have a guidelines to make your code work and do the correct approach, if you make the test after the coding you maybe can have some errors and make bad tests.