Did you ever needed to modify the source code to return some value for the testing purpose? Or you needed to alter the code as so to stimulate some flow? If your answer is yes then I guess you also forgot (from time to time) to revert your change back and such temporary fix went into to repository. If you want to prevent those keep reading

If you want to get rid of those accidental checkins you need to change your way of work. Don’t change the code. Only change the flow. How? I’m glad you asked. Visual Studio (and probably any other debugger) has something called tracepoints. They primary goal is to output some debugging information when they are hit – provide a trace through the code (hence the name). To use the tracepoints you simply right click a breakpoint and select Actions from the menu or press the gear box in the tooltip

menu

gear-box

When you do this you will gain access to the breakpoint menu and there you can change it to tracepoint.

breakpoint-menu

Tracepoint is diamond-shaped

In the section “Log a message to Output Window you can enter the text that will be logged. You can also evaluate variables by using the {variable} syntax. You can also decide whether a debugger should continue execution (then it’s a tracepoint) or not (regular breakpoint).

So knowing this how we could steer the flow of our code without actually changing it? Let’s consider the following code:

while (true)
{
  var key = Console.ReadKey();
  if (key.Key == ConsoleKey.A)
  {
      Console.WriteLine("A pressed");
  }
  else
  {
    Console.WriteLine("Not pressed");
  }
}

Of course it’s just an example but let’s assume that we want to make sure that we always go into the block statement where key read from the console was A. We could of course change the code but then we would need to change it back before committing any changes. How to do it with tracepoints? Lets create one on the if line and in Log a message box put this:

{key = new ConsoleKeyInfo('A', ConsoleKey.A, false, false,false)}

the code would run as if ‘A’ was always pressed. Lets analyse what just had happened here.

screen-shot-2016-09-24-at-08-59-12

Magic? No – we just told VS to run this pice of code when the tracepoint was hit. And we just decided no to print anything but just assign a new value to the key variable. We’ve just created a side effect but in this case it’s for a good cause. And because we kept ‘Continue execution’ checkbox checked VS continue its work after the line was executed.

With this nice technique we can control the flow of our program in debug mode w/o actually changing the code. Of course it makes sense when the code is located somewhere in the loop or called many times in other scenarios we can of course change the value manually.

Just a small warning before we wrapt this up – this is kind of abusing usage of tracepoints – remember it produces side effects those might cause you some hours of analysing weird behaviour of your code. If something is working odd – remove all tracepoints before you pull out all your hair.