It’s time to get back to the T_WebPageTask.CheckCreation unit test that has failed. In the last chapter, we were left with a breakpoint defined prior to the call to Assert. It has failed because the task starting date is not valid:
It looks as if it was never initialized. All we need to do is go into the TodoTask constructor and add the code for storing today’s date as the start-point for the task:
In this way, all the derived classes will benefit from the fix.
When the test is rerun to validate the correction, the final validation fails:
The AbsolutePath property isn't what we expected. This time, let's correct the unit test rather than the code for the class, which is based on the value of an incorrect property.
How do we find the right one?
We display the task and then its property URL to see all the properties available, together with their values:
We can see at once that we need to base it on AbsoluteUri rather than on AbsolutePath:
And now the test passes!
We passed the test, but is it complete? The parameters passed to construct a WebPageTask seem to all be tested. Except that managed enumerations mean that the first value of the enumeration is also the C# compiler default one used when the variable is not explicitly initialized. Was changing the category value during the WebPageTask creation within the test taken into account? Was the value Science (first value in the enumeration) put there explicitly by the constructor code or implicitly by the compiler?
The best solution is to modify the unit test accordingly. However, it’s possible to see and modify the value of variables. So let’s look at how to modify the value of a parameter by rerunning the debugger with a breakpoint prior to constructing the WebPageTask.
It’s very simple! All you have to do is view the value using any of the previously-quoted methods, and then click on the value itself to change it:
The text entry box offers the same auto-complete function as the editor. Once the value has been selected, press ENTER to confirm.
The new value appears everywhere (and even in red to indicate it has been modified during the latest execution):
If the constructor code is now run using the new value for the category using Step Over (F10), you can see that the category for the WebPageTask created is not the right one. Let's revert to the default enumeration value:
And now the unit test’s second assertion fails. :(
To understand where the problem is, let's return to before the execution of the creation of the WebPageTask using Set Next Statement:
And go down into the constructor using Step Into (F11). Only the URL is stored at this level:
The name and category are handled in the code for the base class, which is accessed using Step Into (F11) again:
In fact, this code does not take the contentCategory parameter into account for giving the value of the corresponding Category property.
All we have to do is write the code to fix the problem. We can even do it while we’re debugging!
This involves the Edit and Continue function: once the modification has been made, continue normal execution using Step Over (F10) or Step Out (Shift + F11). However, there is a simpler way of returning to the unit test using the Call Stack panel via a right-click Run To Cursor!
We are back in the test, just prior to the return from the constructor:
Now Step Over (F10) to see the result:
Let's recap!
You have seen how, in addition to viewing your data, the Visual Studio debugger makes it possible to modify its values and even the code without re-compiling during an investigation. 😁
