Conditional breakpoint and cheatpoint

Conditional checkpoints are a practical and powerful tool. Premise is simple: you setup a condition and, while debugging, execution only stops if condition is met. 

The key word here is condition, whose potential is sometimes underestimated even though the conditions input dialog is quite explicit about its options (sorry dialog pic is in Spanish):

So, a commonly missed feature is that breakpoint can stop in case a value has changed. I have no clue why people is missing this (me the first one). Maybe it's a usability problem (put the blame on them, as usual).

The second feature that is often missed it's a misuse of conditional breakpoints which I like to call conditional cheatpoints.

Think about a conditional break point as a function that is called and stops execution depending on its results. Give it an evil twist...  and you have an open door for sloppy code injection! Whatever you state in the conditional break point condition will be executed every time execution flow reaches the line with the break point. BTW, credit for conditional cheatpoints for Jordi Rodriguez, who discovered them to me.

What the hell I am using conditional cheakpoints for?

When I work with slow to compile solutions and I make a mistake which prevents code to take the execution path I would like to test, sometimes I can add a cheatpoint to force code to take the execution path I want without having to stop execution and recompiling it.

Example:

In the following screenshot you can see that I set hasStock to true in the condition breakpoint. This way, even if HasStock method has a bug which returns false by mistake I can force the execution of the stock removal code.