I wanted to raise the coverage numbers noted in my last posting, so I jumped onto the code, looked at the coverage, and realized that I needed another test. I added this is, and my coverage jumped from 35% to ~70%. Good I thought – and went to look at the coverage output to see what other corner case I had not covered.
What I saw was very interesting. All the code was highlighted as being run. Wha?
The SecurityManager.CanUserEditObject method basically does 3 levels of security checks - it checks the layer’s “default policy”, a layer-wide editor role, and finally a per-user, per-feature policy. Thus, the code is structured around 3 nested select blocks… (simplified example below)
Select Case GetDefautlPolicy(obj)
Case AccessGranted
Return True
Case AccessDenied
Select Case CheckRolePolicy(obj)
Case AccessGranted
Return True
Case AccessDenied
Select Case CheckUserPolicy(obj)
Case AccessGranted
Return True
Case Access Denied
Return False
End Select
End Select
End Select
What was interesting was that by directly returning from inside the case statements was causing the code coverage numbers to be lower than you would expect. Since this is a bit of a code-smell, I refactored the code to only have one return statement at the end. That alone got me 10% more coverage – no more actual code was run, but the coverage algorithm liked it better. Below is an image of the code-coverage highlighting.
Even at this point, the Visual Studio code coverage tool is reporting only 87.5% coverage for this block.
Anyhow – the take home here is that the code coverage algorithms are fickle, and even though you tests hit all the code, you may not get 100%.
