3 ms·

Does your team work on a codebase that uses a dynamically typed language? If so then the 100% coverage requirement is perfectly reasonable and arguably the only

by avl999 5y ago

Does your team work on a codebase that uses a dynamically typed language? If so then the 100% coverage requirement is perfectly reasonable and arguably the only sane way to develop anything more than a tiny project. If a statically typed language is being used then sure, that requirement is counterproductive but if a team uses a dynamically typed language I don't see a way to have any reasonable amount of confidence that the code is even syntactically and semantically valid without 100% coverage. The 100% coverage is just a tax that you need to pay in dynamically typed codebases (hence my preference to use statically typed language for any reasonably sized work related project). For 3) TDD has nothing to with test coverage or aiming for high coverage. The fact that TDD evangelists have tried to couple "good testing" with TDD is a huge scam. I don't care when you write your tests as long as they get written before the code is merged in. TDD is good for parts of the code which are very pure or where you know exactly what you are doing, but if what you are doing is more exploratory in nature or is not pure and has lots of external dependencies TDD is simply not practical for a lot of people.

cbhl 5y ago
In my experience, scaling a large project in a dynamically typed language with 100% unit test coverage just gets you production outages with all unit tests passing. A reasonable threshold is probably closer to 70-90% _plus integration tests_. Hopefully you also picked a language where a bigco has created tooling that lets you incrementally add static types -- TypeScript, Closure Compiler, Python typing and/or pytype, etc.
- lenkite 5y ago
  Lol, this is so true. A project that I had joined (late) some years ago had 98%! code coverage, full sonar/fortify code compliance and was an utter piece of garbage that had regular outages in production. It taught me a couple of lessons: 1. Integration and System Tests are FAR more valuable than unit tests. By several orders of magnitude. 2. Performance Tests are vital. This is actually more true in a cloud world. There is only so much hardware you can throw at a problem before your costs are un-feasible.
cush 5y ago
The law of diminishing returns for sure applies here
- rbanffy 5y ago
  It applies everywhere.
oxff 5y ago
This is false. 100% UT in a dynamically typed language like JS is no assurance of anything really. You need to cover all the observable behavior in any case (no matter the type of language) to get any kind of assurance. UT cannot deliver this.

by avl999 5y ago

cbhl 5y ago

In my experience, scaling a large project in a dynamically typed language with 100% unit test coverage just gets you production outages with all unit tests passing. A reasonable threshold is probably closer to 70-90% _plus integration tests_. Hopefully you also picked a language where a bigco has created tooling that lets you incrementally add static types -- TypeScript, Closure Compiler, Python typing and/or pytype, etc.

lenkite 5y ago
Lol, this is so true. A project that I had joined (late) some years ago had 98%! code coverage, full sonar/fortify code compliance and was an utter piece of garbage that had regular outages in production. It taught me a couple of lessons: 1. Integration and System Tests are FAR more valuable than unit tests. By several orders of magnitude. 2. Performance Tests are vital. This is actually more true in a cloud world. There is only so much hardware you can throw at a problem before your costs are un-feasible.

cush 5y ago

The law of diminishing returns for sure applies here

rbanffy 5y ago
It applies everywhere.

oxff 5y ago

This is false. 100% UT in a dynamically typed language like JS is no assurance of anything really. You need to cover all the observable behavior in any case (no matter the type of language) to get any kind of assurance. UT cannot deliver this.