Have a class A, and a Test for it:
-------------------------------
class A() {
public const string foo = "bar";
public int int_prop{ get { return 7; }}
}
[Test]
public void check_const() {
A a = new A();
Assert.AreEqual(a.foo, "bar");
}
------------------------------------
Now, i get a black dot on the left of the int_prop (but nothing on the public string).
My test passes. all are happy.
One day, the big scary troll changes my "foo" constant, and it now reads:
public const string foo = "trolled";
If I manually run my tests from Nunit, the check_const() fails miserably (like it should).
BUT ... NCrunch will still show me the green bar reassuring me everything is ok ... (which leads me to suspect that it's on the troll's pay role)
So, I changed my code back (in our example: foo ="bar"; where it used to be foo="trolled"), and was about to go on with my work ...
Now my Nunit tests are all green and happy ... but ... now Ncrunch is showing me a red bar ...
and complaining that check_const fails because "trolled != bar".
Feels like ncrunch is lagging behind and is running an outdated version of my code... tried saving, modifying, but it's still red (even though code wise, it should pass the test, and Nunit tests pass).
NCrunch won't show markers next to constants, as they aren't represented in the debug information for an assembly. Constants are handled very differently by the compiler (vs normal source code). You'll notice that it isn't possible to set a breakpoint on a constant value - at least, not one that will work. NCrunch is also impacted by this constraint.
When NCrunch shows you the incorrect results for the test (i.e. the markers are red when they should be green, or vice versa), are the markers fully coloured or faded out? If the markers are faded, this means that the engine is still processing and hasn't yet been able to show results for the latest version of your code. There are things you can do to improve engine response time if the response times seem to lag (refer to the performance tuning guide.
If the above isn't the case, and the markers are showing incorrect results with solid colour, try doing a reset of the engine by enabling/disabling NCrunch or by clicking the 'reset' button in the Tests Window.
NCrunch won't show markers next to constants, as they aren't represented in the debug information for an assembly. Constants are handled very differently by the compiler (vs normal source code). You'll notice that it isn't possible to set a breakpoint on a constant value - at least, not one that will work. NCrunch is also impacted by this constraint.
When NCrunch shows you the incorrect results for the test (i.e. the markers are red when they should be green, or vice versa), are the markers fully coloured or faded out? If the markers are faded, this means that the engine is still processing and hasn't yet been able to show results for the latest version of your code. There are things you can do to improve engine response time if the response times seem to lag (refer to the performance tuning guide.
If the above isn't the case, and the markers are showing incorrect results with solid colour, try doing a reset of the engine by enabling/disabling NCrunch or by clicking the 'reset' button in the Tests Window.
they were solid ....
i'll give the magic "turn off, turn on" a try next time i see this ugly beast rear it's head :)