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:
Patent Scam
I have just been (nearly) bitten by a few Registration Services Scams.
Here is how it works:
After a patent has been received in a patent office, the address of the inventors are published and become public knowledge. There are some (Do Evil) companies that scan these addresses and send very official requests for fee’s for supposed services like “Registration Service Fees”.
These letters and envelopes seem so original that I was about to fall for the scam and pay the fee. The only signs of a scam was the payment method which is different than the normal methods used to pay for Patents.
In the end I called my patent lawyer and asked her what the letter was about. She confirmed that it is a scam.
Bookmark at:
ASP.NET Unit Testing just got Easier
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
Bookmark at:
Typemock and .NET 1.1
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?
Bookmark at:
Typemock Isolator 4.2 is released
We have released version 4.2 of Typemock Isolator, now with more features that enable shorter development cycles, higher quality of production code, better tested and more stable software components.
Typemock Isolator V4.2 introduces support of the new .NET 3.5 framework as well as Microsoft’s Visual Studio 2008. Version 4.2 has an improved IDE integration based on using colors to emphasize mocked methods making the best visualization, easiness and comfort for developers to verify their code developments.
On top, Typemock Isolator V4.2 provides full support of synergetic solutions such as Finalbuilder™ and DotTracer™ profiler, making this new release the most powerful testing framework for .NET developments ever.
“We are always seeking ways to help you simplify the development process, and our improved interface and integration with the market leading tools ensures organizations and developers with easiness, better software quality and a true saving of development expenditure”.
Webcast of new features
Mark your calendar for the live special webcast of Typemock Isolator on Wednesday, March 12th at 4PM GMT (8AM PST). To join the webcast and for further details please click here.
Bookmark at:
Typemock and Design Issues
The new field mock feature that enables developers to mock fields has raised the questions:
- Who needs to mock fields, (only bad programmers)?
- Does Typemock advocate bad design?
- Is Typemock too powerful?
Advocating Good Design
Well, lets get one thing straight. I do advocate good design, the design of the software is an important factor and one that I spend a lot of time on. I don’t advocate bad design. But this has nothing to do with testing tools.
Separation of Concerns
Mixing the abilities of tools is not a very good idea, I can give you numerous examples: One is my friends combined DVD/VCR that didn’t last long, the DVD had missing functionality that made the machine obsolete. Having your testing tool and design tool in one can lead to the same results.
I believe in Separation of Concerns - the testing tool should help you test your software and give you the confidence that you code works, it should not (as much as possible) force you (or help you) to design your code. The design tools (refactoring) should enable you to design your code in a better way, it should not test your code. Testing and Designing are different mind-sets. When you are testing your code, you are thinking about the external API and the scenario that you are testing - trying to make the code fail. This is a different mind set then when designing your code, where you need to see the higher picture and how to put all the pieces together. That is why TDD has 3 different steps: Test, Code, Refactor! (Where Refactor is the Design process)
So what about mocking fields
Enabling Field Mocking comes from the same philosophy: Let the developer test his code. There is such a beast called “public fields” in .NET and there are some teams that use them and need to test their code. To give them confidence in there code, we can create pragmatic tools that will enable these team to test their code base and thus help these teams become more agile. If we tell these teams that they cannot test there code unless they conform to one certain design, these teams will not become agile as the bar is too high.
And what about design
There are many tools that developers can use to design there code (before or after writing tests), from static code analyzers like fxCop to refactor tools like Visual Studio and Resharper, and of course code reviews (and pair programming) which I believe are the best tools for design.
Once you separate the testing phase from the design phase you will have the freedom to make the correct balance and thus the best design, Typemock actually helps you get BETTER designed software. As long as you start thinking about the design seriously (by ruthlessly refactoring) and stop relying on your testing tool to do your design for you.
Bookmark at:
Subscribe!
RSS 2.0