Typemock Isolator 7.5 Released

You know how it is when you’re working on something, and you want to release it, but then you want to add just one more thing, and than another?

You may call it feature creep. We call it Isolator 7.5.

And it really is quite a release. Let’s go over what we’ve got here:

SmartRunner is getting smarter and better: it provides the quickest feedback from tests – automatically. This means that you can count on it to run needed tests, so you can pick up early on possible bugs. 

Here’s what we’ve added and improved:

  • SmartRunner now supports NUnit TestCase tests. Parameterized tests have been around for a while, but not everybody uses them. While they have a lot of use in theory, there’s much less actual use that we’ve seen. But that doesn’t mean we can ignore these cases. So now, if all test cases are passing, you get a green shield. If one of them fails, you get a red one. Like regular tests.
  • Tests are now grouped by Test Class in the test navigation window, rather than just listed, giving you a better chance of finding the tests you are looking for.
  • Debugging is now much smoother and quicker. When you start debugging at a tested method level, it breaks only there (whereas before the debugger stopped at the beginning of the tests) – this allows you to save time by skipping directly to the method you want to debug. No unnecessary breaks. 
  • Test invalidation got smarter too. What’s invalidation, you ask? Every time you edit a method, Isolator “invalidates” it, rebuilding the lists of tests to run. You can see these tests as “pending”. Well, editing is not the only thing that requires running the tests. We’ve added also automatic validation to adding test Setup and TearDown methods, that will run all the tests in that class. In addition, tests will run if tested classes are added constructors.
  • We fixed some bugs around shield appearance.  If you played with renaming, copying and pasting code, or re-opening class files, you’ve probably seen glitches in the matrix. So we’ve got lots of them bugs squashed.
  • And of course, we’ve made improvements in speed and robustness, so we won’t need to write about those in the next release (… but we will…).

 

As always, we want you to triumph over legacy code with ease and elegance. We know that testing legacy code is not just about mocking, so we added a few more capabilities to our ArrangeActAssert library:

  • So let’s say you want to create an instance of a type that has no public constructor, instead of building a reflection factory, use Isolator:
Isolator.NonPublic.CreateInstance<T>(...)

In its simpler form it will use And if you pass an argument list, it will identify the correct constructor and use that. Simple.

  • Speaking of non-publics, we’ve also added more abilities for non-public invocation. For example, let’s say you want to invoke a non-public method in a class, only this method is defined in the base class. No worries. The regular Invoke works on that too. Like this:
Isolate.NonPublic.Invoke.Method(underTest, "ProtectedMethodInBase", arg1, arg2)
  • What about if the non-public method argument list has ref or out parameters? Until now, you were kind of stuck. Not any more! Use the Args API to box the arguments and pass them:
var arg1 = Args.Ref(5);
var arg2 = Args.Out<int>();

Isolate.Invoke.Method(underTest, "MethodWithRefAndOut", arg1, arg2);

Assert.AreEqual(4, arg2);
  • Isolate.Fake.AllInstances works great on concrete types. But we may want to do that to many types implementing an abstract class or an interface. Now, when you use the API on one of those, it will fake all implementing or derived types. Saves lots of writing.
  • We also threw in another top request from MsCorLib: Directory. You’re welcome.

We’ve got more fixes, and improvement.

Oh, that TFS 2013 support thing we’ve been passing around secretly for some of you? It’s now public, with its own template.

Much more to come in the future. But for now, go download Isolator 7.5.

TOP