Note that there are some explanatory texts on larger screens.

plurals
  1. POUnit-testing coverage policy, test quality concerns
    text
    copied!<p>our company is trying to increase software quality by enforcing minimum function coverage on automated unit-tests. This is already a good starting point to get at least some tests written and to get them automated (although it would be better to go for branch or decision coverage). </p> <p>My main concern is the outcome of the tests which are going to be written after this policy is taken into use. I have seen too often such rules causing huge amount of null testing (i.e. nothing is asserted) or some maintenance nightmare kind of integration tests. I found following SO questions close to the subject but these concentrate more on coverage percentages:</p> <p><a href="https://stackoverflow.com/questions/695811/pitfalls-of-code-coverage">Pitfalls of code coverage</a></p> <p><a href="https://stackoverflow.com/questions/90002/what-is-a-reasonable-code-coverage-for-unit-tests-and-why">What is a reasonable code coverage % for unit tests (and why)?</a></p> <p>Instead, I would like to get help or insight, how we could avoid awful quality of tests. So here's a couple of most worst unit-test no-nos and what I have already thought for avoiding them:</p> <p>1) Null testing</p> <ul> <li>Code review for test code also</li> <li>As we use testing framework, assertation are done by using FW macros. Maybe we could write some tool which would calculate ratio for assertation per method call of class under testing. No idea yet, what would be good enough ratio.</li> </ul> <p>2) Integration tests </p> <ul> <li>Again review</li> <li>Perhaps some code analysis tool to check dependencies of test code to production code. Test class should have very little amount of dependencies to other classes (except to the one under testing) of the tested system.</li> </ul> <p>There's plenty of teams and I am not totally convinced that team-internal reviews would be enough in all cases. Therefore I would be more interested in ways of automating quality ensurance.</p> <p>TIA, lutku</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload