4

I'm currently researching and deciding on a code coverage tool for my company, and have so far tried NCover (Bolt and Desktop), DotCover, and NCrunch. All tools I've tried so far work well for measuring/highlighting code coverage in code called directly by unit tests, but any code called through CSLA (DataPortal_Fetch, for example) is never detected as being covered. As much of our code base resides in these functions, I'm finding the tools to be next to useless for much of what I need tested and measured.

My question then is how can I get code coverage results for CSLA code? Does anyone know of a tool that would work with these kinds of calls, or certain options/extensions I can use to get coverage results with the tools I'm using?

The project is coded in C#, and I'm using Visual Studio 2013 Professional, CSLA 3.8, and .NET 4.0. I have the latest versions of NCover Bolt and DotCover (both on trial), as well as the newest OpenCover that I could find.

Thanks in advance!

The Boondoggler
  • 105
  • 1
  • 8
  • I don't think you are going to find much due to CSLA being heavy on reflection (which is your problem with the Fetch). That is one of my biggest pet peeves with CSLA. – TyCobb May 05 '14 at 16:04
  • You want coverage on functions invoked by CSLA (through reflection) and can't get it? – Ira Baxter May 11 '14 at 06:08
  • I need coverage of my custom CSLA functions called after the internal CSLA reflection calls are made. That is, when I call DataPortal.Fetch<>(blah), internal calls are made, then my DataPortal_Fetch(blah) function that I have in my business class (no separate DAL) is called. This second function isn't getting caught by code coverage by any tool I've tried thus far. – The Boondoggler May 12 '14 at 14:37
  • I've written unit tests for Csla objects and dotCover seems to figure out that the DataPortal_Fetch is called. I am sure because it highlights the code. I'll point out that the unit tests always use the local dataportal. I'm also running with R#8, but nCover on our build server worked fine too. Did you change any of the default coverage options? – Andy Jun 02 '14 at 00:41
  • Is the CSLA code being executed in the same process as the rest of the code? If you have a sample then I may be able to investigate further with OpenCover instrumentation (no guarantees). – Shaun Wilde Jun 03 '14 at 02:40
  • @Andy, my unit tests don't use the local dataportal, which is probably one of the complicating factors. I haven't tried setting up nCover on the build server, which might still work. As for coverage options, I've tried every configuration I could think of that might get the coverage I need, no dice :( – The Boondoggler Jun 23 '14 at 18:18
  • @AndrewS Yes, I would think that would affect coverage. If your unit tests are using a remote DP, you could perhaps conditionally compile out the DP_XYZ methods which would correct your coverage metrics, but unless you have something that actually exercises the remoting host like Csla would you won't be able to get coverage of your DP_XYZ methods. I'd suggest though having your unit tests not use the remote data portal, as that just increases the complexity of your tests. I think the coverage tools can only work with one process and remote DP is a different one. – Andy Jun 23 '14 at 19:25

2 Answers2

1

Unlike TyCobb's entirely outdated opinion, current versions of CSLA don't invoke methods via reflection (except on iOS) and haven't since around 2007. But the data portal does use dynamic invocation via expression trees and that's probably the issue causing you trouble.

One option in current versions of CSLA is that the data portal is now described by an interface so you can mock the data portal, potentially creating a mock that does nothing but invoke your DP_XYZ methods directly. Even that's tricky though, unless you make them public and allow other code in your app to easily break encapsulation (yuck). The problem is that you won't be able to call the methods without using reflection, or rewriting the dynamic expression tree invocation code used inside CSLA...

Though perhaps the code coverage tools would see the code executing if it were run via reflection instead of via a runtime compiled expression?

Rockford Lhotka
  • 842
  • 6
  • 9
1

NCover Support here.

If you are using NCover Desktop, you can auto-configure to detect any .NET code that is being loaded by your testing (Bolt can only profile test runners).

We have this video that shows auto-detecting NUnit, as an example: http://www.ncover.com/resources/videos/ncover-creating-a-new-code-coverage-project

And a lot of the same info in this help doc: http://www.ncover.com/support/docs/desktop/user-guide/coverage_scenarios/how_do_i_collect_data_from_nunit

Please contact us at support@ncover.com if you have extra questions. Hope this helps.

NCover Support
  • 271
  • 1
  • 4
  • I've actually been in touch with your support quite a lot since my last edit, and for whatever reason (still unsure) Desktop wasn't detecting the code being run. I'll double check the links you suggested to see if I might have missed something! – The Boondoggler Jun 23 '14 at 18:13