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:
Decorator feature enhancement
[Cross Posted in TypeMock Insider Blog]
Typemock-Isolator has a little know Decorator feature that allows developers to simply add capabilities to their test framework (all test framework).
Using this feature Typemock-Isolator creates the [VerifyMocks] decorator that automatically verifies the mocks at the end of your tests.
To create a custom decorator simply extend the DecoratorAttribute and implement the Execute method.
public override object Execute()
{
// Trace start of method
Console.WriteLine(“Entering Method:”+
OriginalMethod.ToString());
// Execute the original method
return base.CallDecoratedMethod();
}
To support multiple decorators on the same test method, Typemock-Isolator makes sure that even if a developer forgot to call CallDecoratedMethod() the test method will still run. This is done by calling the decorated method if it wasn’t explicitly called.
We discovered that some Decorator implementers want more control and need to explicitly make sure that the test method was NOT called.
A new API was added in version 4.2 to do just that.
Once this is called (inside Execute), the decorator mechanism will not call the test method.
Of course if there is another decorator on the test method that calls CallDecoratedMethod() the test method will be executed.
Bookmark at:
Tips and Tricks
I am happy to announce that we have opened a Typemock Blog 
The blog will host posts from Typemock developers and will give inside information and tip and tricks.
Lior Friedman has already posted a explanation of the difference between Mock and MockObject
Bookmark at:
Typemock Isolator - Beta - Better Community
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
- Mocking using Generic Code Sugar
- Integrated Visual Studio Help can now be downloaded by all Typemock-Isolator users
- Per your request*: The annoying feedback screen while in evaluation, has been removed.
Mock mockControl = MockManager.Mock<ClassToMock>();
* The majority of feedbacks we received was to remove the Feedback Screen 
Bookmark at:
TypeMock Ltd has Secured $1.5M
I am delighted to announce that TypeMock has managed to secure $1.5M.
We have had an excellent year, and have 
seen how unit testing is starting to become a main trend in writing software. There are still many problems to solve in this area and we have raised the money to create new tools and solutions for the community as well as innovate and push developer testing to a new level.
At this point I am going to be taking the position of the CEO. I still have a sweet spot for coding and will stay tuned to all the technologies and will post features on this blog. TypeMock has already become a very strong team and you will be hearing about our new tools in the near future.
Happy new year
Bookmark at:
A Big Welcome to Roy Osherove
I would personally like to give Roy a big welcome to the TypeMock team.
I have worked with Roy while introducing TDD to an enterprise ‘legacy’ software company and have been wanting to work with Roy even since.
Roy has decided to join TypeMock at an excellent time, and will bring his expertise to help us produce better tools and promote pragmatic unit testing throughout the .net software industry.
Good Luck Roy.
Bookmark at:
Debugging Mocked Methods
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?
Bookmark at:
Welcome Ron Shoshani
I would like to welcome Ron Shoshani to our Team.
TypeMock is having a great year and we are growing, Ron will head the Marketing activities in TypeMock and will help introduce tools and techniques to developers around the world, enabling them and their teams to create quality software at speed times.
Welcome Ron!
Bookmark at:
TypeMock Facebook
TypeMock now has a facebook page. The industry leaders are already there. Don’t miss the party.
Click here to join the typemock group
or the typemock page.
Bookmark at:
TypeMock and Visual Studio 2008
Although we have supported visual studio 2008 since the Beta version I still think that it important to know that TypeMock supports visual studio 2008.
Bookmark at:
Subscribe!
RSS 2.0