3 ms·
Adequate test coverage is hard without rebuilding from scratch. Hard to expect in a big, old company. Except when a huge codebase have to be rebuild because pyt
by orwin 6y ago
Adequate test coverage is hard without rebuilding from scratch. Hard to expect in a big, old company. Except when a huge codebase have to be rebuild because python2 have to be replaced (one of our software provider is in this case).
- WJW 6y agoOut of all the items on the list (code reviews, CI, etc), it seems like test coverage would be the simplest to improve? Assuming it has a test suite at all, use one of the various test coverage scanners (simplecov, coverage.py, etc) and check the output for a file with a low % of lines covered. Then write one or more tests to cover the edge cases not yet tested. It's a purely mechanical process unlike most of the other problems which depend on changing the behaviour of people in different departments and/or with more influence than you.
- loopbit 6y agoDepends, code that was not written with testing in mind can be very difficult to cover without some major refactoring. Adding the first tests can be a slow and painful process. Now, once you have those few tests? Yep! Add a few tests along the ones for the new functionality every time you touch a piece of code or pick the low hanging fruit every now and again and you can get to a useful test suite in no time.
- bizzleDawg 6y ago"It's a purely mechanical process" - I thought on this for a while. I think if your testing is purely mechanical then you're probably not getting much value from it. Good tests need to be "smarter" than the code they are testing in a way. Unit testing, for coverage (as a vanity metric) can be mechanical maybe, but integration tests are the way more valuable ones (for the most part) and way more complex.