Smart thoughts on code coverage.
Code coverage can't tell you how well something is tested, or even if it is tested at all, and it makes for an actively harmful quality target. Code coverage is a dev tool, not a status report. #gametesting #gamedev #testautomation
thoughts on building quality software in the 21st century
Five for Friday – April 26, 2024
thoughts on characters and personalities in the workplace
Five for Friday – April 19, 2024
You get to work with meeee toooo - unless you don't like me, then I promise to leave you alone. But seriously, Brittany is awesome, and this is a great role.
We're on the lookout for a Sr. Program Manager to join our awesome team at NBCU! If you're ready to take on new challenges, work with a fantastic group of people, and make a real impact, this could be the perfect opportunity for you!
my past and future infatuation with CI systems
Five for Friday – April 12, 2024
why you can't solve every problem with the same hammer
Five for Friday – April 5, 2024
Author is spot on. I did a lot of testing on servers. My joke/rule of thumb was that you got a free 30% code coverage just by starting the server. I remember one time reviewing a module that was presented to as 100% code coverage. Someone had written tests against the getters and setters on every field to close the final mile. My comment to the engineer showing me this was "So, essentially, you are testing the C# compiler." Meanwhile, when surveying test code for APIs that used the same 100% covered classes, not a single one of those tests ever passed in a class with those covered properties set to a value, which did have an effect on functionality in those components. I said to the engineer "I don't care about the get/set coverage, what I care about is that none of these APIs were ever tested with this field's value set to true." Coverage metrics motivate bad behavior.