try-with-resource unit test coverage

Question

I wanted to ask if you have any techniques for covering try-with-resource with unit tests. I'm using it to open some stream and eclemma is showing me that I have uncovered branches on this try-with-resource block. I understand that this block is apparently translated into something else after compilation, but does that mean that I can't have 100% coverage with emma if I use this? Do you have any techniques to handle this issue? I like my coverage 100%.

Thanks!

Could people that down voted for this question give me reasons why they did that? This is a perfectly valid question and any personal preferences (probably wrong and invalid) on code quality shouldn't be a reason to do that. — alobodzk, Oct 14 '14 at 13:32
I agree with your sentiment on desired 100% coverage. For me though its more about OCD desires. In one project I refactored the try-with-resources into a few separate very simple methods, so I could easily isolate and test the various pieces independently. — ruckc, Jul 08 '15 at 22:36

score 9 · Accepted Answer · edited May 23 '17 at 12:32

9

The short answer is no.

Long answer: As described here: 8 branches for try with resources - jacoco coverage possible? a try-with-resource gets compiled into a very complicated group of statements where some branches are probably not reachable by everyone's code.

As of now (Oct 2014) Jacoco (eclemma) does not filter those unreachable branches for you however there is a ticket to do that but I don't know if it or when it will ever be implemented.

While 100% code coverage is nice, it's not a good metric to blindly follow. 100% code coverage doesn't tell you anything other than you have tests that execute all your lines of code. Your code can still have bugs if that covered code does the wrong thing or doesn't do enough. Over the years, I've found many bugs in regions of code that were 100% covered because while I had tests that covered all the statements, I didn't consider all the edge cases so my code behaved incorrectly on rare occasions.

Also, if your project is large enough, these missed branches will hardly make a difference. So what if you only have 99% coverage.

edited May 23 '17 at 12:32

Community

1
1

answered Oct 14 '14 at 15:20

dkatzel

31,188
3
63
67

1

Thanks. I agree generally, but If you have a 100% coverage, you have some degree of certainty that you don't have a dead code, because you've looked at least once on all your code while developing tests and you don't have to speculate which parts of code you can skip because it's "not that essential". It's also a great way to avoid weird but possible language constructs. – alobodzk Oct 14 '14 at 15:55
3

Just to put the significance of the problem back into perspective, in my case (custom DAO library), the best branch coverage I'm able to get with *try-with-resources* is 57%. Your statement of "so what if its only 99%" severely understates the number of missed branches. – Parker Apr 08 '16 at 20:00
Unless your library is all try-with-resources, having full coverage elsewhere should eventually make the few lines missed in the try blocks insignificant which is what I meant – dkatzel Apr 09 '16 at 04:27

score 1 · Answer 2 · answered Nov 04 '14 at 08:25

I did this:

public class Something implements AutoCloseable {
    private HttpAutomationClient client;

    //methods for connecting, etc

    @Override
    public void close() {
        shutdown();           
    }

    void shutdown() {
        client.shutdown();
    }   
}

public class SomethingTest { 

    //stuff
    @Test
    public autocloseableShutsDownTheClient() {
        final HttpAutomationClient client = mock(HttpAutomationClient.class);
        Something something = null;
        try  (final Something spy = spy(new Something())) {
            something = spy;
            TestHelper.setField(something, "client", client); //sets a field using reflection
        }
        verify(somehing).shutdown();
        verify(client).shutdown();
    }
}

score 0 · Answer 3 · answered Oct 14 '14 at 12:09

0

While writing the test cases, actually we should focus on functionality rather than test coverage. If you want to cover those areas, better use some mock tools like jmockit to cover those try areas

answered Oct 14 '14 at 12:09

dasrohith

533
2
8
21

I agree with you, that functionality is most important, but 100% coverage gives you other benefits. – alobodzk Oct 14 '14 at 13:30
Obviously quality wise you can tell that you have cent percent coverage. But I would like to mention that 'scenarios' for getting the code coverage is important rather than 'just coverage' – dasrohith Oct 14 '14 at 16:00

try-with-resource unit test coverage

3 Answers3