Hi,
Resharper has 2 very handy features that help quickly fix compile errors:
1. Navigate previous/next errors using keyboard shortcuts (Resharper uses Alt+Shift+PageUp/PageDown);
2. Display errors of current file besides the vertical scrollbar:
External image
It would great if NCrunch has similar features help quickly fix broken tests.
Feature Suggestions
Navigate previous/next broken test using keyboard shortcuts
Started by ylee on 7,325 views
Remco NCrunch Developer
#1541
24 Mar 2012 21:32 UTC
Hi Ylee -
I've been thinking a bit about this feature, particularly the navigation one.
The interesting question around this is what should be considered a failure point. Naturally NCrunch has information on both build failures and test failures, and the navigation to a failing test could be one or all of the below:
1. The deepest point in the call stack of an exception thrown
2. Any other point in the call stack (an X shown on the markers)
3. The beginning of a test that is failing
I guess the main difference between analysing a test failure and analysing a build failure is that build failures are usually very local. When you have a failing build, it's usually possible to highlight the one area that is causing the problem and give it meaning within a small context. In order to analyse a test failure, you really need to know what the test is doing and how it arrived at a particular result.
What are your thoughts on this?
I've been thinking a bit about this feature, particularly the navigation one.
The interesting question around this is what should be considered a failure point. Naturally NCrunch has information on both build failures and test failures, and the navigation to a failing test could be one or all of the below:
1. The deepest point in the call stack of an exception thrown
2. Any other point in the call stack (an X shown on the markers)
3. The beginning of a test that is failing
I guess the main difference between analysing a test failure and analysing a build failure is that build failures are usually very local. When you have a failing build, it's usually possible to highlight the one area that is causing the problem and give it meaning within a small context. In order to analyse a test failure, you really need to know what the test is doing and how it arrived at a particular result.
What are your thoughts on this?
Edited 24 Mar 2012 21:33 UTC
Thanks for your detailed reply, Remco.
Sorry, but I don't have much experience in software development, so I'm afraid I cannot evaluate the technicalities.
But for the 3 choices, I vote for #3: beginning of a test that is failing :)
Sorry, but I don't have much experience in software development, so I'm afraid I cannot evaluate the technicalities.
But for the 3 choices, I vote for #3: beginning of a test that is failing :)
Post a reply
Log in to reply.