TDD-style unit tests are great for languages that do not provide contracts. Alas, the majority of popular languages don't provide this facility.
For languages that do provide contracts (Eiffel, D, Spec#, Sing#, M#, and soon C++20), unit tests are still useful to fill in the gaps that contracts don't cover, but there will not be nearly as many unit tests.
The biggest value for TDD-style unit tests is how it impacts the design. It is a forcing function for YAGNI, KISS, DRY code (and WET unit tests), Clean Code, TDA ("Hollywood principle"), and a good portion of SOLID.
The residual secondary value of enabling refactoring with confidence is very liberating. And the tertiary value of having a unit test suite as a byproduct to ensure basic correctness from regressions is good too.
I'd value those things as x1000 value for better design, x35 value for refactoring with confidence, and x1 value for ensuring basic correctness.
The other point I like to make about the difference between unit tests and other kinds of tests is that unit tests should be written by the developer as a development aid, run super quickly (seconds) for the entire unit test suite, which are run in debug mode. (It is somewhat unfortunate that "Test-Driven Development" has the word "test" in it, because some developers seem to think that tests should be written by quality engineers and not the software engineers, or that "Test-Driven Development" is about the testing -- which it is not, it is all about the design.)
In contrast with other kinds of tests like integration tests, performance tests, usability tests, acceptance tests, system tests. Which should be written by quality engineers, run against the optimized release builds, and may take hours or even days to run the full test suite.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
TDD-style unit tests are great for languages that do not provide contracts. Alas, the majority of popular languages don't provide this facility.
For languages that do provide contracts (Eiffel, D, Spec#, Sing#, M#, and soon C++20), unit tests are still useful to fill in the gaps that contracts don't cover, but there will not be nearly as many unit tests.
The biggest value for TDD-style unit tests is how it impacts the design. It is a forcing function for YAGNI, KISS, DRY code (and WET unit tests), Clean Code, TDA ("Hollywood principle"), and a good portion of SOLID.
The residual secondary value of enabling refactoring with confidence is very liberating. And the tertiary value of having a unit test suite as a byproduct to ensure basic correctness from regressions is good too.
I'd value those things as x1000 value for better design, x35 value for refactoring with confidence, and x1 value for ensuring basic correctness.
The other point I like to make about the difference between unit tests and other kinds of tests is that unit tests should be written by the developer as a development aid, run super quickly (seconds) for the entire unit test suite, which are run in debug mode. (It is somewhat unfortunate that "Test-Driven Development" has the word "test" in it, because some developers seem to think that tests should be written by quality engineers and not the software engineers, or that "Test-Driven Development" is about the testing -- which it is not, it is all about the design.)
In contrast with other kinds of tests like integration tests, performance tests, usability tests, acceptance tests, system tests. Which should be written by quality engineers, run against the optimized release builds, and may take hours or even days to run the full test suite.