- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
It's worse than that, in fact. It doesn't test the
toStringmethod, since it doesn't look at what's returned. At best, it tests that it obeys the core contract of the methods, i.e. that they return something versus a NULL...It doesn't even verify that
toString()returns a string, ffs.Admin
assert(FRIST==FRIST);
Admin
TRWTF is that the project management office didn't see it coming, and just kept piling projects on the lead dev, with no fallback plan.
Admin
Whenever someone mentions a code coverage target I always point out that I can meet that target without providing any value and I can write super valuable tests without getting anywhere near that target. Way more important to test useful things, but it's not like management would know what that looked like if it hit them square in the face.
Admin
The fact the lead's departure percolated up to the C-level says either the whole company is real small, or the PMO was essentially powerless and the mismanagement and extreme under-resourcing and overpromising goes all the way to the top. Which situation, though a major-league meta-WTF in itself, is so very common in our industry as to elicit nothing but a "Ho humm, move along, nothing to see here." reaction from me and I suspect from most of us. Which in turn is the meta-meta-WTF to rule them all.
Admin
Gee I wonder why the dev bailed.
Admin
Well there's your problem: they should try using Gantt charts instead.
How? Surely your coverage metric is the percentage of your code that is exercised by the tests. Unless the constructor,
toString()andequals()methods are very large, the percentage is surely going to be close to zero.Admin
Sort of, except that calling the boilerplate generated methods(1) will create a chunk of pointless "coverage", which boosts the percentage without actually adding much.
(1) As I noted above, the calls don't actually test those methods, since the returns are not checked for correctness, unless two new blank objects should compare equal.
Admin
Fully agree with the easy reader version. I rather use snippets to generate boilerplate than "magic". "Magic" works wonders, until it doesn't...
Admin
Mutation testing would have caught those absolutely useless "tests". Y'all feel free to spread this meme I made:
https://twitter.com/DaveAronson/status/1595077882199834624/photo/1
And if you don't yet know about mutation testing, you can pick one of these conference talks of mine on it, of various lengths (and therefore depths): https://www.youtube.com/playlist?list=PLMrm16n64Bub8urB-bsyMyHiNPMLG7FAS
Admin
Ah, useless unit tests so that management can check something on their imaginary success list. Never gets old.
Admin
I hope they don't take test coverage percentage to be the minimum %'age of tests that pass in order for the build to be accepted.
Admin
No, no, the percentage of passing tests is only allowed to drop by 5% at a time...
Admin
"as that one developer's tasks were on every critical path on their Gannt chart. " - Root cause identified.
Admin
To me it looks like they set a minimum code coverage for acceptance, combined with unrealistic deadlines. Then the dev started playing the metrics to meet the deadline or at least miss it by less.
Who could ever have seen it coming?