Comments by "Ton Bong" (@tongobong1) on "DON'T CHASE TEST COVERAGE!" video.

@salvatoreshiggerino6810 I was also fired for tying to save a year of useless work long time ago. I was right - the project was total waste of time and it was stopped after almost a year but it had a purpose of getting money from customer - it was a fake project for an excuse for financial transaction. Since then I don't argue much against bad ideas from management.
1
Exactly. Unit test should exist to test functionality (the unit of functionality) and not to test some code - method or class just to get coverage.
1
The problem with TDD is that it is not applicable to every code - the code that uses a lot of random data where you should see the final result, graphic rendering...
1
Only bad tests are bad. It is better not to have bad tests. Good tests will help you develop much faster with fewer bugs and will give you the control over complexity of the code so you can create much more complex logic without getting into huge trouble working on it - extending it, refactoring, redesigning and fixing bugs.
1
@ContinuousDelivery I wonder what do you propose for teams working on large code base that don't do TDD and have less than 10% coverage. Should they write more unit tests or it is better to continue without unit tests?
1
Focusing on code under test is bad when writing unit tests. We should always focus on functionality that we want to test instead.
1
Unit test should be a black box test that knows nothing about the implementation of functionality it is testing. There is the London unit testing style that is coupling unit tests to the classes they test and that style is just terrible. Use the classical unit test style.
1
You don't need tests for tests because tests should contain only trivial logic so no loops or conditions or complex calculations. Tests for trivial logic in production code are usually useless so you shouldn't write them.
1