Solidity-coverage: Safe transfer and not coverable assert() failure

[Adrion]

Not really an issue but I'd like to know how to manage error case for these kind of lines :
assert(token.transfer(msg.sender, token.balanceOf(this)));
I added an assert to add extra security if something goes wrong.

But in my tests I can't make this fail. So I can't get 100% on branch coverage.
It's an example but I have some extra asserts for cases we can't reproduce in the test environnement.

[cgewecke]

@Adrion Yes! This is an interesting issue. In web frameworks like Angular there are often special mocks for the server layer that allow you to simulate any response in the tests.

Perhaps a solution could be as simple as a truffle resource that gave you the ability to tell testrpc to error the next transaction?

rpc.fail();
// Call method that hits: assert(token.transfer(msg.sender, token.balanceOf(this)));
rpc.stopFailing();

[Edited example per below]

[area]

I think the assert is in the Solidity code, not the javascript test. The rest of this comment assumes that to be true.

From the Solidity docs

If used properly, analysis tools can evaluate your contract to identify the conditions and function calls which will reach a failing assert. Properly functioning code should never reach a failing assert statement; if this happens there is a bug in your contract which you should fix.

And so... yes, if the assert is appropriate (rather than it should be a require), then you should not be able to to make it fail. It's not clear to me if solidity-coverage should take that in to account, however, when reporting coverage.

[cgewecke]

@area Good point. Do you think in this case it should be a require? Can you give an example of a case where assert is clearly more appropriate?

What happens if I instantiate token at the wrong address and call the method?

[cgewecke]

Closing for house-keeping. Thanks for raising this point though. May need to revisit.

[area]

I'll also just say for people finding this later: code coverage is just a tool. 100% code coverage doesn't mean that your code is flawless, and less than 100% doesn't necessarily mean that your code (or tests) are bad. Striving for 100% coverage might be a waste of developer time. If you understand why you're failing to reach 100% coverage, and it doesn't imply poor code (as in this instance), then it's perfectly okay!

[AntonioJuliano]

Just chiming in later here, it would be really nice if there were the option to ignore assert statements in branch coverage. Agree with what @area posted earlier, in most cases it shouldn't be possible to make an assert fail, so not testing them doesn't necessarily imply lesser coverage