What would YOU DoInstead? The Sequel

So last time, I showed you how to do something before a method is called. That’s nice but what if you want to do something after it’s called?
Let’s look again at the code under test:

The API we used in our last venture is:

As you probably can guess, it’s the part that tells Isolator to run the original code. We didn’t call it in the future tense, though. The method will be executed after the code in the DoInstead clause is completed.

In our next case, we want the Authenticate overload with 1 parameter to also run. But we want to log (and maybe even assert) the static variable LogInCounter.

Now, we need a way to tell Isolator to invoke the method, and continue running. Let’s take a look at this test:

We see that if we call the Authenticate with 3 arguments, it will be executed once the DoInstead clause completes.

However, when the overload with 1 argument we use another option. CallContext.Method contains the metadata of the method that’s being called. With that metadata, we can invoke it before the DoInstead completes. And we can do something after the method.

We know that the definitive AOP example is logging. Is it useful to more than that in a testing context?

Imagine that the Authenticator.IsUserAuthorized method might crash the system sometime. Or leave the system unclean. For our purpose, we want to run it as-is and not mock it, but when it crashes we don’t want to ruin it for the other tests.

In this case we can do something like this:

When the method IsUserAuthorized is called, we run it inside a try-catch-finally block, which allows us to the recovery and clean up we need when going to the next test.

What other AOP functionalities did you ever wished you had while testing?