Releasing Isolator 5.0 and Racer alpha
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.
Bookmark at:
Technical Support, our policy pays
I have spoken before about our Support Policy, and it seems that it pays off, as good technical support is one of the differential factors when choosing Software tools according to Soon Hui
I must first thank our great team of developers that are in the front line of our customer support as well as being in the front line of the technology and development world.
As a team we get a lot of feedback from the issues that our customers have and we become better developers, as we know how to add real value to our customers. Being transparent about this (through our online public forum) and having communication skills and collaboration as a value, just makes us a better team. (It is also an Agile value)
Bookmark at:
Is the visibility of tested methods important?
We are having quite a discussion lately about the importance of the visibility of tested methods.
See our internal Blog for the juicy stuff
Bookmark at:
Who is old formula
I was talking with a friend who just turned 37 yesterday. We were talking about how as you grow, being ‘old’ seem to be a moving target.
We managed to find this simple formula to find out who is old:
For a child of 4, 20 seems old
When you are 16, 40 seems old
When you are 25, 50 seems old
For my friend 60 seems old
The nice thing about this formula is that when you are 100 you know that you are old
Bookmark at:
Mocking frameworks - dream feature
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!
Bookmark at:
Interesting Unit Testing Survay
According to a Telerik Survey (brought to me by Avi Kaye) Unit Testing is still not mainstream.
I am not sure how many people voted, and although the result might surprise some of you, these results confirm what I think about the implementation of automated unit tests.
Unit testing is still quite difficult and there is a need for better tools to help with the pain.
Bookmark at:
Typemock Isolator 4.2.4 is available
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
Bookmark at:
Ruby Style Mocking in .NET
I had a great discussion with a college about the difficulties of understanding the technical parts of the automated Mocking frameworks.
The one point that takes some time to grasp is the fact that methods are written within the test that are not actually called, but are stubs/mocks that will be called at a later time. This is true to all frameworks. He then suggested that having the ability to swap one type with another would help in understanding the flow of the test. So I whipped together some code to do just that.
Using this code it is possible to swap one type with another. The two types must have the same methods, but the swapping type doesn’t need to have all the methods of the original type.
Here is an example:
public class OriginalClass { public int ReturnOne() { return 1; } public static int StaticReturnOne() { return 1; } }
Static Method Swapping
Suppose we want to fake the static methods of the OriginalClass, we simply write a new class.
public class FakeClass { public static int StaticReturnOne() { return 2; } }
Note: apart from the names of the methods the two classes are not related.
Here is how we fake the calls,
- We Swap the OriginalClass with the FakeClass by: Swap.StaticCalls()
- All static calls to OriginalClass methods that exist in the FakeClass are diverted to the FakeClass.
- We Unswap the types at the end of the test by Swap.Rollback()
[TestMethod] public void SwapStatic_CallsFake() { Swap.StaticCalls<OriginalClass, FakeClass>(); Assert.AreEqual(2, OriginalClass.StaticReturnOne()); Swap.Rollback(); }
Instance Swapping
We can do the same with instances, we can create a new FakeClass and swap the instances.
public class FakeClass { public int ReturnOne() { return 2; } }
Note: again, apart from the names of the methods the two classes are not related, but they both might implement the same interface or base class and thus support refactoring.
Here is how we fake the calls,
- We Swap the next new OriginalClass with the FakeClass by Swap.NextNew().
- All calls to that OriginalClass method which exist in the FakeClass are diverted to the FakeClass.
[TestMethod] public void SwapInstance_CallsFake() { Swap.NextNew<OriginalClass, FakeClass>(); OriginalClass swappedInstance = new OriginalClass(); Assert.AreEqual(2, swappedInstance.ReturnOne()); }
Missing Methods
At this stage the missing methods of the swapped type can have 2 behaviors:
- Call the original class (Default or UndefinedMethods.CallOriginal)
- Do nothing and Return a default value (UndefinedMethods.Ignore)
This is set in the swap statements.
Downloads
Bookmark at:
Understanding Mock Objects - Better Design
Azam has written a post about Ben Hall’s article “Beginning to Mock Using Rhino Mocks and MbUnit“. The logic in the example is a method that returns an image of the sun in the day and the moon at night. In both Azam’s and Ben Halls examples, the GetImage()method returns the image name
public string GetImage() { int currentHour = DateTime.Now.Hour; if (currentHour > 6 && currentHour < 21) return "sun.jpg"; else return "moon.jpg"; }
Using Interface only Mocking Frameworks will lead to redesigning this in order for the code to be testable and extracting and wrapping ‘DateTime.Now’ to an interface and concrete class:
public interface IDateTime { int GetHour(); } public class DateTimeController : IDateTime { public int GetHour() { return DateTime.Now.Hour; } } public class ImageManagement { public string GetImage(IDateTime time) { int currentHour = time.GetHour(); if (currentHour > 6 && currentHour < 21) return "sun.jpg"; else return "moon.jpg"; } }
Scott Bellware has suggested a better design - and that is to move the ‘is it day or night’ logic from the ImageManagement class to the IDateTime
The calculation of whether it is day or night is an orthogonal concern of the image generation and therefore should be moved out of the GetImage method.
Now our code will look at following:
public interface ITimeService { public bool IsDayTime(DateTime time) } public class ConcreteTimeService : ITimeService { public int IsDayTime(DateTime time) { int currentHour = time.GetHour(); return (currentHour > 6 && currentHour < 21) ; } } public class ImageManagement { public static string GetImage(ITimeService time) { if (time.IsDayTime(DateTime.Now)) return "sun.jpg"; else return "moon.jpg"; } }
The first thing to note is that being forced to use interfaces and Dependency Injection (the first example) did not naturally lead to a good design - there is still a need to think about the design in classical - old fashion - Object Oriented terms.
But if we are thinking about designing in the old fashioned way, here is another approach to reach the same (or better) results: using extension methods, which is a much more natural way of doing this in .NET 3.0+
public static class DateTimeExtensions { public static bool IsDayTime(this DateTime time) { int currentHour = time.GetHour(); return (currentHour > 6 && currentHour < 21) ; } } public class ImageManagement { public static string GetImage() { if (DateTime.Now.IsDayTime()) return "sun.jpg"; else return "moon.jpg"; } }
This makes more sense as we are extending the abilities of DateTime, the code is easy to read and understand. The only problem is how do we test this code.
Well it is simple with Typemock Isolator here is how:
[Test,ClearMocks] public void WhenItIsDayTime_ReturnSunImage() { // pretend it is always day using (RecordExpectations r = RecorderManager.StartRecording()) { r.ExpectAndReturn( DateTime.Now.IsDayTime, true); } Assert.AreEqual("sun.jpg", ImageManagement.GetImage()); }
So here are two points to think about:
- You must always think about your design, using IoC and DI does not automatically lead to better designs
- If you are already thinking about your design, you might as well have the freedom to develop the design you reached, without limitations of your tools
Bookmark at:
Why Typemock-Isolator for TDD?
There is a long discussion in the ALT.NET group about TDD and Typemock, it is very interesting and I suggest that you read the thread.
Benefits of TDD
Although the benefits of using TDD are inconclusive, here are some benefits attributed to using TDD:
- Developers write more tests
- Tests use the API, so developers can get early feedback on the API design
- Developers have more Focus as the tasks are divided into small chunks
Why do we need to Mock?
In order to use TDD effectively the tests must
-
Run fast.
-
Run in isolation.
-
Self Contained.
-
Race Safe.
-
Independent.
In order to make sure that we have fast tests, that the tests are self contained and don’t rely on external resources, we need to test our code in isolation from the rest of the system. This is done by mocking out components that are not part of our test, and testing only the unit logic.
TDD and Typemock-Isolator
So where does Typemock-Isolator fit in and how does it compare to other frameworks?
When using TDD with legacy code or 3rd party libraries, the benefits of Typemock-Isolator are well known, so I will not talk about those area’s but about green-field projects.
Developing with Typemock-Isolator, developers will be able to do all the stuff the other frameworks and manual mocks/stubs allow with the addition of being able to mock static methods, private methods and types and a chain of calls (fluent interfaces) in one go (As well as better integration with Visual Studio).
These features make it simpler to divide the code into small chunks - leading to more focus and more tests.
The API’s are still reviewed as tests are written using the API so early feedback of the API’s are part of this process. This is achieved with the freedom to use any internal design of the unit: Extension Methods, Linq, Fluent interfaces, Singletons and Factories.
Other frameworks will force the developer to use DI as an internal pattern. This might be good, but might not be good. It might leave public API’s that where not meant to be public. It will leave the ability to inject an alternative implementation that might ruin the system. It will probably lead to developing extra functionality to support validating and error handling of the injected components. This might be a YAGNI smell that will require extra development and tougher maintenance. Is DI a silver bullet design pattern? Or do you want the Freedom to refactor the code to best suit the product - I know that I do, this is what Typemock-Isolator will give: The benefits of TDD with the freedom to refactor your code to any design.
Bookmark at:
Subscribe!
RSS 2.0