Object Oriented Testable Designed – You must be out of your mind

Eli Lopian    .NET Tests    

Roy has posted a new design methodology: Object Oriented Programming that is Testable!

Roy and I are on the opposite sides of this methodology. I personally hate to change my production code just for the tests.
As Roy says “pure object oriented design does not go well hand in hand with the notion of testable design.” After creating a good design (without taking testability into account), there is no real business value of implementing hooks to change internal private members and to expose properties that should remain private by design! Unless you want to clutter your code with load of Totally Irrelevant Code

Please, Stop Designing for testability!!

There is no need to do this, using the right tools you can enjoy both worlds.
We all have have seen testable code. The code is hard to maintain and understand. A Testable code, will have many interfaces that have no real design value, that will just confuse developers. Have you ever tried to browse a code with loads of interfaces, it take ages because you have to keep finding the concrete implementation, and the place where the instance was created.

Think about this code smell: When you find that an interface and implementation have exactly the same public methods, it is a sign that the interface is not exposing a trait of the object but the Object itself. This is what happens when your code is Designed for Testability, you do have a safety net, but the design is flawed.

Using TypeMock.NET your code can be encapsulated (OOD) and Testable at the same time:

• OOD: Do not expose any private members or methods that are not needed by the developer using your API .
• Testable with TypeMock: Easy to replace private instances of objects without changing your code or exposing unnecessary parts
• OOD: Seal classes to inheritance by default unless you explicitly mean for others to extend them
• Testable with TypeMock: No need to extend and override your objects just to test them
• OOD: Only make methods virtual explicitly when you want others to override them.
• Testable with TypeMock: Keep your methods non virtual (its faster). you can still test the code.
• OOD: Use singletons to make sure only one instance exists. do not allow anyone to touch that private instance.
• Testable with TypeMock: Don’t allow others to replace Singleton instances, TypeMock will do it for you in your tests.
• OOD: make types private or internal by default unless you want to expose them specifically.
• Testable with TypeMock: Keep your types private so that you can hide the implementation, you can sill test the code
• OOD: Don’t add unnecessary API’s
• Testable with TypeMock: No need to clutter you production code with special API’s

Evil Singleton Mocking with Natural™ Mocks

Eli Lopian    .NET Tests    

Ok, so we all know that Singletons are Evil, and Hard to test but sometimes you just have to be bad.

We have added some more support for Singletons in the coming TypeMock version.
With Natural™ Mocks, it is quite easy to mock a Singleton. Here is how: 

public class MyServer {
   public string Host {
      get {  return Singleton.Instance.GetHost(); }
   }
}

[Test]
public void TestSingleton()
{
   string expectedHost = "wow";
   using (RecordExpectations record = new RecordExpectations())
   {
      Singleton.Instance.GetHost();
      record.Return(expectedHost);
   }
   MyServer server = new MyServer();
   Assert.AreEqual(expectedHost, server.Host);
   MockManager.Verify();
}

Couldn’t be simpler:
TypeMock will know that Singleton is a singleton, and will do all the mocking for you.

How Windows Vista Security helped us make a Faster Application

Eli Lopian    .NET Tests    

Part of the coming TypeMock.NET version, we completed our support for Vista Machines.

TypeMock.NET has been compatible with Windows Vista for quite some time now, the only feature that was missing was the Tracer.
Although the Tracer is not required to run tests using TypeMock, it is very handy when your mocks are not working well.

Using the Tracer it is possible to see the expectations the instances of the mocked types and where the code didn’t meet the expectations.

Shared Memory

In .NET 1.1 we used a Shared Memory Paradigm to pass information from the test to the tracer. This worked very well, but in Windows Vista, you have to be an administrator to create a global shared memory. This is not always possible, we need to be able to test an application in normal scenarios and we don’t want to be forced to be an administrator. I am not really sure why there is such a security issue with creating a global shared memory, I will be happy to hear for you.
Since .NET 2.0, there is support for IPC (Inter-Process Communication) Remoting using named pipes, we decided to use this option. We decided to try to use the shared memory implementation first, and if we fail to create the memory we will use the IPC. This way we won’t have the problem of the Tracer running in .NET 1.1 and listening to the shared memory, while the tests are running in .NET 2.0 and are sending trace information over IPC.

After some testing and refactoring, the tracer worked on Vista, but we had a suprise.
We found that using IPC was 3 times faster!!! then our shared memory implementation.

We changed the code. This time the tracer will listen to both the shared memory and the IPC port. TypeMock will then first try to communicate using IPC, if it fails it will try using the shared memory.

TypeMock.NET Build Statistics

Eli Lopian    .NET Tests    

We are almost ready to release TypeMock.NET 3.7.0

Here are some statistics of our build system.

• To build TypeMock we use two MSBuild scripts, the scripts also calls NAnt scripts (To test the NAnt integration)
• We build TypeMock using CruiseControl.NET. 
• Our codebase is built once and can run on .NET 1.1, 2.0 and 3.0
• We have 1274 tests that are run twice (on .NET 1.1 and .NET 2.0) that take 97.487 seconds with CodeCoverage.
• 23 of the tests are ignored (Features that are not implemented yet, or are impossible to test automatically)
• We have a 75.6% coverage
• We cannot use TypeMock.NET to test ourselves.
• Our testing frameworks are NUnit, Visual Studio Unit Tests and mbUnit – (We must test all those integrations too).
• We run coverage using NCover, Clover.NET and Visual Studio Code Coverage (We test all these integrations as well).
• Our build system builds all the documentation (using NDoc and a proprietary tool), the installation kits (using Wix) , installs the software and then performs a series of smoke tests.

Here are some items in our wishlist

• We still need to merge all the tests and coverage result from the different frameworks into one page.
• We also want to automatically deploy the installation into several Virtual Machines to test different scenarios. We are doing this manually.

[Update] Fixed MbUnit link, thanks Andy 

Creating a Trade Show Booth

Eli Lopian    .NET Tests    

This is the first time that TypeMock had a Trade Show Booth. We googled and read all the blogs about creating a Trade Booth and I must tell you that we put a lot of effort into this.

There is allot of production work to do. From renting the booth, creating the art, getting little bits and pieces working together. (You might call this the build system – and it always takes more resources then you expect).

We decided that we are not going to have any brochure. I remember going to these shows, collecting all the brochures just to leave them on my desk for a couple of months until they reach the bottom of my todo pile, gather dust just to be thrown out.

Instead we created a “Be Agile – Mock the System” cool promotion movie to play on a plasma screen, and fixed up a cool Demo to show wandering developers how cool TypeMock is. Of course we had a fish bowl full of jelly-beans. But I think that the highlight were Toma and Alisia our amazingly agile assistances who wore a small wireless LCD screens playing the movie. Real Cool.

Here are some pictures. A big thanks to all the people who put time and effort into creating it. Notice the new TypeMock Logo comming out soon.

 
Building the booth

 
Ohad behind the booth (Notice the TypeMock Shirts)

 
Toma getting wired

Toma and Alisia

Ohad and I showing the Magic

 
Alisia doing her stuff

   
Ohad Being Agile (See the Plasma Screen)

 
Toma and Alisia on the show floor

Oren Eini (Ayende) and I.

Ohad and I (Notice Travis Illig’s quote: “Holy shit this thing is hot“ playing on the screen) 

Thrown into reality

Eli Lopian    .NET Tests    

I had a Great Time at the Microsoft Developers Academy.

We had a great booth and met loads of developers. Meeting all these developers really helped me get a perspective. As both our customers and internal development are using TDD Methodologies or at least Automated Unit Tests I have been having the feeling that everyone is already unit testing and working in iterations to get maximum coverage. Truth is that this is nowhere near the reality. Although most developers have heard of unit testing and nUnit (which is an improvement) most do not practice this at all.

Here are some of the answer I got when asking developers if they unit test.

1. We don’t test, we have a QA team to do that!

2. We don’t need to test, we are great programmers!

3. We are too far down the project to start testing!

4. My team can’t test because (something technical …) but I will interest the other team (because their code really $#%$.)

5. Our customer/management doesn’t want us to waste time writing non production code!

I didn’t answer these during the show and I am not going to answer these now, but I know that I have past the no-going-back point.

I actually feel wrong when I write code that doesn’t have a test, as if a big red warning light starts flashing “You are going to regret this”.