There’s one breaking change in Isolator v4.2.4. A small one really. The ValidateArgsOnVerify flag is now obsolete, and Isolator will throw an exception both when calling the method and on the Verify method.
Well, for those who know about this flag this sentence may seem reasonable, but for the rest of us, let’s run through what was, what will be and why.
The context is checking arguments. Let’s look at this example:
|
1 2 3 4 5 6 7 8 9 10 11 |
[TestMethod] public void CheckArguments_SendAnotherName_ExpectException() { using (RecordExpectations recorder = new RecordExpectations()) { ProductFactory.HasProduct("Name"); recorder.Return(true).CheckArguments(); } ProductFactory.HasProduct("AnotherName"); MockManager.Verify(); } |
In the recording block, apart from setting the expectation and return value, we make sure that the parameter to the HasProduct is “Name”. As you can see from the code, we send “AnotherName”, which is a mismatch, and therefore throws a VerifyException.
The exception is thrown when the HasProduct method is called. So we don’t even get to the MockManager.Verify line. This was a limitation some of our customers could not live with, and they asked us to allow to delay the exception throwing until Verify was called. We graciously accepted this, and so the ValidateArgsOnVerify was born.
Using this flag is an either/or only: the default (which is false) throws on the method itself, and when set to true, we’ll throw on Verify. Usually that’s enough. Now let’s change our example a bit:
|
1 2 3 4 5 6 7 8 9 10 11 |
[TestMethod] public void CheckArguments_SendAnotherName_ExpectException() { using (RecordExpectations recorder = new RecordExpectations()) { ProductFactory.HasProduct("Name"); recorder.Return(true).CheckArguments(); } ProductFactory.ReadProductFromFile(); MockManager.Verify(); } |
The expectations are the same, but we’re calling the ReadProductFromFile method, which looks like this:
|
1 2 3 4 5 6 7 8 9 10 11 12 |
<span class="kwrd">public</span> <span class="kwrd">void</span> ReadProductFromFile(<span class="kwrd">string</span> productName) { <span class="kwrd">try</span> { <span class="kwrd">string</span> <span class="kwrd">value</span> = ReadFromFile(); ProductFactory.HasProduct(<span class="kwrd">value</span>); } <span class="kwrd">catch</span> { Console.WriteLine(<span class="str">"Logging The Error"</span>); } } |
Wrapping I/O operations with try/catch blocks is common practice. So what will happen when no I/O problem occurs, but a VerifyException is thrown because of argument mismatch? It gets swallowed. And since we’re throwing the verification only ONCE, we now have the case of the missing exception. And as we know, there’s no police around when you need them.
Well, not anymore. From now on, we’ll be throwing exceptions right and left. Actually, both on the method call AND the Verify method. There will be no escape. And that’s why the ValidateArgsOnVerify is no longer necessary.
Another case where the truth comes out eventually. Because, as we all know, the truth is out there.
