Nicer Tracing with [VerifyMocks]

Eli Lopian    .NET Tests, Debugging    

An unknown feature, (at least till this blog) of the final version of TypeMock 4.0 is the Tracer Utility. Up till this version each time you called MockManager.Init() or when TypeMock started a new sessions the Tracer showed an Initialization (#number) to make it possible to trace the mocked calls.

The reason for this was that we just didn’t know that names of the tests. But when using the [VerifyMocks] attributes, we already know the names of the tests and we incorporated this into the Tracer. So using the decorators will make it easier to trace your mocks

Notice the names of tests actually appear in the tracer. Cool!

New TypeMock Site

Eli Lopian    Release    

We have redesigned the TypeMock site

Apart from the graphics and new layout we have added more content:

• Examples and How To’s
•  Cheat Sheets
• Product Feature Matrix with expandable feature descriptions
• Partners Page
• On Page Help and FAQ
• TypeMock seal of quality 

I would be happy to hear what you like about the site, but I also welcome any suggestions or criticisms, too

Good Programming is about Balance

Eli Lopian    .NET Tests, TDD    

This post hits the nail on its head:
When good programming practices are just too good.

What struck me … is the ridiculous amount of code required to implement simple things.

I love this paragraph

We all love rules – with them, you don’t have to think much, you just apply what the smart guys think is the best. However, lately we younger generation begin rebel and declare these rules as “elitist crap”.

Good programming is an art, and thus good programmers question and think about all aspects of their code. We don’t just follow rules, we invent them.

Design vs. Process

Eli Lopian    .NET Tests, TDD    

Oren Eini has posted Tools vs. Design about the Really Simple Dialog post.

It is NOT the design that will give you the freedom to expand and build extendable and maintainable systems. It is impossible to see the future and to implement the best design, that is what YAGNI is about. It is the process that will allow us to meet future requirements. A process that will allow us to change the design as the features grow.

Lets recall the TDD process:

Write Tests -> Code -> Refactor (Design)

Notice that the Design stage is the LAST stage, it is not:

Design (For Testability) -> Test -> Code

Of course we need Tools to support this process, the tools are a testing framework, continuous integration server, and perhaps a mocking framework to allow testing your code no matter what design you chose. We might end up with the same design that Jeremy started with, but we might not. The code might be simple enough to just be there, saving time maintaining the complex MVP code, that many developers are still learning. We do have the option to change this in the future if our code is becoming complex enough to require this.

Using this process we can give our customers business value and shorten the Time To Market, while leaving the option of growth when needed.

I will conclude, a good process is critical to building maintainable, customer value systems, on the other hand shouting out OO Principles will not ensure this

Extending Test Frameworks

Eli Lopian    .NET Tests, TDD    

One really nice feature of TypeMock.NET 4.0 is the ability to extend any/all testing frameworks.

Each test framework has (or lacks) its own extension mechanism, making it hard add extension to all the frameworks. With TypeMock we can now write an new test decorator that will work for all frameworks, including vsTest and nunit, and all runner-tools including TestDriven.NET and ReSharper.

Actually, It is possible to decorate and extend ANY method! As long as it is run with TypeMock enabled. So it is now really simple to implement Roys Enterprise Services to do database testing, and Ian’s Even simpler way for ALL testing frameworks, without rewriting the test framework, extending base classes or forcing ALL tests in fixture to rollback.

We will be able to write the following test:

[Test,Rollback]
public void Insert()
{
      //Do some inserts into the DB here and automatically roll back
}

Here is the code that does it
[UPDATE: Fixed according to Jonas comment]

[AttributeUsage(AttributeTargets.Class | AttributeTargets.Method,
  AllowMultiple = false, Inherited = true)]
public class RollbackAttribute : DecoratorAttribute
{
    public override object Execute()
    {
        using( new TransactionScope(TransactionScopeOption.RequiresNew))
        {
            // run the test 
            return base.CallDecoratedMethod();
        }
    }
}

It is possible to rollback on all tests by decorating the class

[TestFixture,Rollback]
public class DatabaseTests
{
      //Do many DB tests here and automatically roll back
}

We have implemented the [VerifyMocks] and [ClearMocks] using this technique.

TypeMock 4.0 released

Eli Lopian    .NET Tests    

We have fixed most the defects from the beta and have released version 4.0.

Thank you beta users!