Software Engineering came to help reduce the unpredictability and high cost of Software development. Most of the software engineering practices were created to help address this. Requirements engineering, tests engineering, prototyping, they all serve the same purpose. At the core, It’s all about reducing risk and increasing reliability.
What about code coverage? It’s not a practice. It’s a metric. It tells us how much code was hit during test execution.
Some people fall in the trap of believing that 100% of code coverage means bulletproof code. It just means what it is: your test cases were able to reach every single line of your code.
Does that mean your code is good or you tested it enough? Of course not. That’s how empty the code coverage metric is.
Code coverage itself doesn’t measure the quality of your code nor your tests. You may have 100% of code coverage on a totally broken code. Mário Júnior
That’s why code coverage can’t be blindly trusted. Judging the effectiveness of tests by their code coverage is a bad a idea.
Then what should you use code coverage for? To know how much code your didn’t test yet. You get to decide if its relevant or not to test such code.
100% of code overage != 100% tested.
Never ask someone how much code coverage is considered good. If someone ask you, don’t tell him/her a number. Just tell him/her this:
The best code coverage for your project is the one that lets YOU confident about the code you have written.
Do not let the code coverage drive your testing process. Let the requirements drive your testing process, because your code is supposed to do something. Make sure your code does what it should and doesn’t do what it shouldn’t.
Also keep in mind something very important: Reaching every single line of a bad code during tests, wont turn that code into a good one.
The Funds transfer example:
Functional code 100% tested that will crash in production:
public void FundsTrafersImpl implements FundsTransfer{
public void transfer(String origin, String destination, double amount){
Connection db = getConnection();
if(origin.length()<10||destinatio.length()<10)
throw new IllegalArgumentException("Origin and destination account must have 10 characters");
if(amount<1)
throw new IllegalArgumentException("Minimum allowed amount is 1")
try(db){
//Do the transfer here
}
}
}
Writing tests only to reach 100% of code coverage:
Just making sure you hit all the lines
public void ExampleTest{
@Test
public void transfer_must_suceed_if_amount_is_higher_than_zero_and_account_numbers_have_10_digits(){
//test code comes here
}
@Test(expected=IllegalArgumentException.class)
public void transfer_must_fail_if_amount_is_less_than_one(){
////test code comes here
}
@Test(expected=IllegalArgumentException.class)
public void transfer_must_fail_if_account_numbers_have_less_than_10_digits(){
//test code comes here
}
}
Writing tests to assert the actual behaviour of the method :
Making sure you test most scenarios
public void ExampleTest{
@Test
public void transfer_must_suceed_if_amount_is_higher_than_zero_and_account_numbers_have_10_digits(){
//test code comes here
}
@Test
public void transfer_must_fail_if_amount_is_less_than_one(){
//test code comes here
}
@Test
public void transfer_must_fail_if_account_numbers_have_less_than_10_digits(){
//test code comes here
}
@Test
public void transfer_must_fail_if_account_numbers_have_more_than_10_digits(){
//test code comes here
}
@Test
public void tansfer_must_fail_if_account_numbers_have_empty_spaces(){
//test code comes here
}
}
When you test focused in getting 100% of code coverage, you miss the point, which is: make sure the code works as expected, not as written. This is the point. Keep it in mind. It’s about what you expect from the code, without considering how the code was written. Its about the requirements verification.
A good tests suite should be able to detect behaviour that should be there but is not. You can have 100% of code coverage with a completely useless test suite that helps you achieve nothing but giving you the illusion that “you tested your code”. Think about it.
It’s always a pleasure to share.
Comentários Recentes