Slow unit test runs forever

Thanks a lot, Remco,

We will proceed to order NCrunch very soon.

Hi Remco,

Regarding this, does it mean that afterward code coverage will not be 100% accurate? It would be a big problem for us.

Thanks,

Alberto

devdept wrote:Hi Remco,

Regarding this, does it mean that afterward code coverage will not be 100% accurate? It would be a big problem for us.

Thanks,

Alberto

Not necessarily. It depends upon the extent to which you use it.

When you suppress code coverage for a region of code, NCrunch won't consider that code to be part of the code coverage calculation. So it won't consider this code to be covered or uncovered (it's considered 'not code').

So if you're doing this for large regions of code, it may have a slight impact on your overall metric, but it won't sway it much in one direction or the other.

Note that it is impossible for any tool to track code coverage without some level of performance impact.

We love performance impact if reasonable. We would run only a few unit tests instead of thousands. The problem is that some of them run forever.

How would you identify critical code sections?

Thanks,

Alberto

devdept wrote:
How would you identify critical code sections?

Sorry, I'm not sure if I understand this question .. are you asking for a better way to find performance bottlenecks in your code?

Sorry, I'm not sure if I understand this question .. are you asking for a better way to find performance bottlenecks in your code?

No bottlenecks in the NCrunch instrumentation, in other words where to place these: https://www.ncrunch.net/documentation/concepts_code-coverage-suppression

devdept wrote:
No bottlenecks in the NCrunch instrumentation, in other words where to place these: https://www.ncrunch.net/documentation/concepts_code-coverage-suppression

Right now the best way I can suggest is to follow the yellow markers. Start from the top of the stack (at the test code), then follow them down through into your code to see where it's running slow. With the nature of your codebase, the likely loss of performance is from the markers themselves, and they'll detect their own performance cost.

We're presently working on a 'hot spots' view that will make this easier to do from a more global perspective. It's still experimental at the moment so I can't promise an ETA on this feature.

Hi Remco,

We have a large code base and thousands of yellow marks, I don't know where to start. "Analyse line execution times" turned on or off does not make any difference.

Something you can try is adjusting the performance display sensitivity setting to something a bit higher. You can tweak this so that it only shows yellow markers on lines of code that are extremely slow. This should reduce the clutter somewhat and help to focus on the areas where the performance is most in need of attention.

Thanks Remco, we have 2400 *.cs file in our solution, shall we check manually each one or is there a better way to follow these yellow marks?

devdept wrote:Thanks Remco, we have 2400 *.cs file in our solution, shall we check manually each one or is there a better way to follow these yellow marks?

Start from the top of the stack, inside your test code. You can follow the yellow markers down through your code. This will give indication of where the code is slow inside your test, then through your production code.