Ruby Style Isolating – Aspect Faking

Eli Lopian    .NET Tests, Product, TDD    

I have talked in the past about Ruby Style Isolating (Dynamically Typed), now it is part of the AAA syntax. 

The big value of this feature is that you don’t have to inherit a type in order to replace it with a fake, the downfall of this is that when you refactor your code, you might fail the test.

There are many uses. One example is if you have a class without virtual methods,  you can still overload it and swap the real type with the fake one.

This gives you testability strengths and the ability to keep your design intact.

Example Suppose we have the following class:

public class NiceClassWithoutVirtual
{
    public int NonVirtualMethod()
    {
        return 30; // an example not virtual
    }
}

Now we want to use a manual Stub to replace our NonVirtualMethod: we can do the following: note the new before the method.

public class FakeNiceClass: NiceClassWithoutVirtual
{
    public new int NonVirtualMethod()
    {
        return 2; // our fake value in new not virtual method
    }
}

We can use the Stub as follows

var real = new NiceClassWithoutVirtual();
var fake = new FakeNiceClass();
Isolate.Swap.CallsOn(real).WithCallsTo(fake);

All real.NonVirtualMethod() calls will be directed to fake.NonVirtualMethod()

Fake an Aspect

Note that any methods that are not defined in the swapped type will be run as normal. This allows ‘Aspects’ of the original class to be faked. It is possible to fake a group of methods that have a specific meaning, for example just the ISerializable aspect or just the IEnumerable aspect – so we can fake the collection behavior aspect of a type. This is exactly how we implemented the Swap-Collections Feature. 

Releasing Isolator 5.0 and Racer alpha

Eli Lopian    Product, Release    

We have been working very hard this summer and we are just ready for 2 major releases.

Isolator 5.0

Based on customer feedback we are going to change our pricing model and add 3 new packages

• Special Bundle, containing:
  • Typemock-Isolator
  • Annual Update Subscription
  • Ivonna for ASP.NET testing
  • TestDriven.NET for seamless Visual Studio testing
• Personnel License, for single developers will cost only $199
• Open Source License, for Open Source projects will be free

We have also added a new API for better structured isolation (Mock, Stub, Fake…).

Highlights are:

• No need to understand the difference between Mock, Stub, Fake, Double they all use the same API.
• Easier to automate isolation by recursively faking all chained (sub) calls so:
  

  ClassToIsolate faked =
    Isolate.Fake.Instance<ClassToIsolate>(Member.ReturnFakesRecursivly);
  // now all sub calls will be faked, so this will not fail
  faked.GetSomething().Parent.GetDetail().DoSomething();
  
  // can setup return values via
  Isolate.WhenCalled( ()=> faked.GetSomething().Parent.GetDetail().Name)
     .WillReturn("Cool");
  
  

• Better structure of interaction validation. No recording stage and validation done at the end of the test (aka, AAA- Arrange,Act,Assert)

  // A. arrange
  ClassToIsolate faked =
    Isolate.Fake.Instance<ClassToIsolate>(Member.ReturnFakesRecursivly); 
  
  // A. act
  ClassUnderTest.MethodUnderTest(faked);
  
  // A. assert
  Isolate.VerifyWasCalledWithAnyargument(
  ()=> faked.GetSomething().Parent.GetDetail().DoSomething());
  
  

Racer Alpha

Our newest product helps solve a huge problem for multi-thread/multi-core software development, by automatically finding and pinpointing deadlocks. To use the racer simply call a multi-threaded code via the API and the Racer will start running and re-running the code in different permutations to find the deadlocks. Once a deadlock is found, you can debug the code straight to the problematic permutation!

The Racer uses both Dynamic code analysis and Static code analysis to perform its magic.

See a preview of Typemock Racer on Roy’s Blog

See an example on how to find the deadlock of the Dining philosophers problem.

Of course both the tool play well together and you can validate multi-threaded code in an isolated component.

Is the visibility of tested methods important?

Eli Lopian    Product, Release    

We are having quite a discussion lately about the importance of the visibility of tested methods.

See our internal Blog for the juicy stuff

Mocking frameworks – dream feature

Eli Lopian    .NET Tests, Product, TDD    

There are some developers SHOUTING, that mocking static and  non-virtual methods is a big No-No. Roy, is calling them dogmatic.

Come on guys, the most requested feature from Rhino.Mocks is the ability to mock non-virtual and static members, and Oren has even implemented these when possible (MarshalByRef Objects). I am sure that if it was easy, Daniel would do so too.

In other languages where objects can be swapped without Dependency Injection, there is no-one, calling these features – Bad Practice, just the opposite. They are called ‘Power features’, because that is what they are.

You might prefer to sweat and spend a lot of your time figuring out how to make your code testable, and you might find it easier in your company to introduce a free tool, but please, don’t call a tool that gives you lot of pain,  forces you to use DI (even if you don’t really need it) and to spend time creating utterly useless wrappers – a feature!

Typemock Isolator 4.2.4 is available

Eli Lopian    Product, Release    

Typemock Isolator 4.2.4 is available for download.
This is a patch release with many bug fixes.

• “Invalid Operation Exception” when working with NHybernate and XML serialization was fixed.
• Complex LINQ queries are now mocked correctly.
• Manual assembly loading does not cause an exception. AssemblyResolve event fires correctly.
• RepeatAlways now works correctly following WhenArgumentsMatch.
• Returning values of types that inherit from generic type now work correctly.
• GetMocks return the correct mocks for abstract classes and interfaces.
• Following undeploy Typemock Isolator remains registered.
• Methods up to 30 parameters can now be mocked.

Get the juicy development information here

ASP.NET Unit Testing just got Easier

Eli Lopian    Product, Release    

There is a lot of talk about unit testing ASP.NET. Artem Smirnov  has managed to build a new tool for writing unit tests for ASP.NET. The tool called Ivonna is available as a beta release.

Ivonna is built on top of the Typemock Isolator framework and facilitates running unit tests in the same process as any other unit test, on the client machine, as well as having a specialized API

To start using, see the Getting Started page on the cool site that Artem built. Artem is kind enough to add a forum for feedback – Please use it.

I am sure that there are other packages that can be built for other component to help simplify unit testing, feel free to contact us and we will help you develop these packages

Typemock and .NET 1.1

Eli Lopian    Product, Release    

Although we still have many developers using Typemock in .NET 1.1, now that .NET 3.5 is out, we are going to drop the support for .NET 1.1. in our next version.

Version 4.2 will be the last version to support .NET 1.1. This will allow us to support better .NET 2.0+ features and support better type-safe programming.

Any objections?

Typemock Isolator – Beta – Better Community

Eli Lopian    Product, Release    

The Typemock team has released our next version of TypeMock.NET.

We are calling it Typemock-Isolator. As Typemock helps developers Isolate their code from the rest of the system and make it Testable.

The main reason behind this are our plans to create more tools that will help simplify writing unit tests.

The Brain-Storming sessions behind this name where fun and we actually decided on a name, coded it in and then changed the name a few times after that (talk about agile teams). But the team took these changes really well!

Roy and Paulo have already talked about some new features.
Mainly Better Debugger Integration and Mocking Fields!!!

We have decided to add more features to our Community Edition and some features that were in the Professional Edition and can now be used in the Community Edition

1. Mocking using Generic Code Sugar

Mock mockControl = MockManager.Mock<ClassToMock>();

 

2. Integrated Visual Studio Help can now be downloaded by all Typemock-Isolator users
3. Per your request*: The annoying feedback screen while in evaluation, has been removed.

* The majority of feedbacks we received was to remove the Feedback Screen

Debugging Mocked Methods

Eli Lopian    Product, Reviews    

Although strict XP practices, value tests more then debugging, there are many cases where you still have to debug the code base to find defects. Doing this with mocked objects can be very fishy.

Evaluating Mocked Properties

When evaluating methods and Properties in the Debugger, the Debugger Hi-Jacks the running application to run the code that evaluate the values. A mocking framework doesn’t know that you are running in the debugger and will return the mocked value. This might cause the test to fail, because of unexpected calls or different return values.

Breaking While Recording

When in Natural Mocks recording block, breaking inside the block will lead to very strange results. This is because the Hi-Jacked threads that are evaluating Properties are being recorded and mocked. The current workaround is to turn off automatic property evaluation.

Debugging Mocked Methods

When stepping into a mocked method, or putting a break point on it, you will never reach the break point. This is because the method is mocked and is never actually run. This is very confusing and I have heard some developers spending a lot of time trying to understand what is happening.

Preview

These issues have been a major feature of our coming TypeMock version and will all be solved.

• Mocked Property and Method Evaluation will not change the test!
• Breaking in the Recording Block will nor mess up the recording!
• There is a visual cue that will allow you to see that the method is mocked.

Example of debugging a mocked method.

As you can see, it is very easy to see that the method is mocked and understand why you cannot step into the method.

What do you think of the visual cue?

We are thinking about adding more information to the editor

• Return Values
• Conditional Returns (based on arguments)
• Different instances

What other information would you like to know while debugging?

The Ultimate Proof for TypeMock

Eli Lopian    Product, Reviews    

When developer using TypeMock find it an indispensable tool, it is a sign that we really help ease the task of building lasting software.

Karell says it better:

The best way to see if you need something is to stop using it (or be prevented from using it) for a while and see if you reach out for it out of habit….

I quickly realized that TypeMock.NET had become such an important part of my testing process that I could no longer function without it. It is an indispensable tool and while I acquired another Mock tool I simply can’t do without TypeMock.NET.