The Typemock Insider Blog

Designing for testability: The good, the bad and the ugly

2010-02-07T17:14:00.002+02:00

On February 13, 2010 in Microsoft premises in Prague, there will be a series of ongoing short presentations about .NET.

Gil Zilberfeld will lecture online @ 13:30 CET “Designing for testability: The good, the bad and the ugly”

If you design your application for testability, you’ll have a better architecture, components will be decoupled, and the sun will rise every morning. But is testability really the goal? You will want to watch out from taking it too far.
It’s time to talk about what designing for testability really is – the good and the bad. Your architecture and your project can benefit or suffer from the choices you make. In this webinar session, Gil Zilberfeld from Typemock is going to discuss the pros, cons and alternatives.

Gil Zilberfeld has been in software since childhood, starting with Logo turtles. After 15 years in commercial software companies, he has vast experience in development and development practices. Currently Gil is the Technical Evangelist of Typemock, promoting unit testing and some incredibly cool tools.

Sweepstake 3rd week in a row, Next drawing this Wednesday The 10th

2010-02-07T15:31:00.002+02:00

Free Isolator 2010 Every Week

Welcome to the Easy Unit Testing Family. By now you are probably Following Typemock @ Twitter

AND only for that you will be included in every Wednesday Drawing from now until the End of February, unless you already won or will win Before :))).

The rules are very simple:

make sure that you are following us on Twitter
To finalize your registration please Tweet from your personal twitter account

Just entered to win an Isolator 2010 to enter & keep up with latest unit testing news, follow @typemock & RT

http://bit.ly/7SVQkx

That’s it!

You may Email us your contact information to Social@typemock.com

Good Luck!!!!

More from this week Typemock TV

2010-02-05T15:36:00.002+02:00

Typemock TV

2010-02-05T15:16:00.002+02:00

“This Week In Testing” Episode 12: 3 Guys, a Girl and a Bunny (Part 1)

2010-02-05T11:23:00.001+02:00

It’s amazing what you can do with tripod. We’re not going to show you that.

Instead we’re going back to animal discussions. And there’s some some testing related issues as well.

Enjoy our new settings, beer and crew. We did.

Part 1 is here.

This week in Testing Part 1

2010-02-05T01:14:00.002+02:00

How many tests do we have for Isolator?

2010-02-04T13:41:00.001+02:00

we’re big fans of using FinalBuilder and TeamCity, and we’re big fans of testing and continuous integration as well, so it’s only fitting that you see a sneak peek at what our continuous and nightly build runs contain in terms of testing:

yep, about 10,500 tests for the nightly build.

“…I want Typemock. It makes life so much better.”

2010-02-03T19:52:00.001+02:00

This past weekend I received an Email from Roy Oshorove, the email was CC’d to the entire company and the message:

“read how he saw it. also - he gives a great idea for an intellitest feature. see if you can figure out what it is!” and he attached a link to a Blog Post Written By Brandon D’Imperio “Unit Testing Made Easy with the power of typemock”

It was pleasure to read and as our Development Manager said, it was almost emotional to get an outside perspective, that we not only help the developers with our great tools, but that our product is exactly the product that they were looking for, everything they can ask for and more…

Brandon wrapped up his post with these words

“I did not have to alter my code to fit the tests. I did not have to think about testability when writing the code. I did not need any special assembly attributes. I want TypeMock. It makes life so much better.”

and our Development Manager, couldn’t ignore it, and Emailed all of us

“This is so exciting I am getting emotional. This is exactly the vision we had in mind to lower the barrier for people who want to unit test with our tools. Great job, team!" said Doron Peretz - Development Manager @ Typemock

Thank you guys for sharing your success stories with Typemock

Have a Great one and don’t forget to follow us on twitter

2nd Twitter Sweepstake Drawing

2010-02-03T18:38:00.001+02:00

Hi guys,

We are happy to announce our 2nd winner in the Twitter Sweepstake, and this week the winner is :

Dan Forsyth @DannOh from Burlington Ontario, Canada.

We already announced the winner, and we are happy to Welcome Dan to the Unit Testing Family…

“Thanks Tal, I'll be sure to send out a tweet. I love the product and have been using it on a project recently, be great to have my own license. Dan”

You are Welcome!!!! And for the rest of you guys, there is still a chance to win in our next Drawing, that will take place a week from today on February 10th 2010.

Good Luck

And Don’t forget to follow us on twitter.

Brian Mains on Focusing on Testability - An Example

2010-02-02T13:50:00.001+02:00

Brian Mains wrote a nice post on how to modify the code for better testability. Now, it’s not that the code is not nicer, but testability hasn’t changed – it was testable before and it remained so after.

I’d like to repeat Roy’s comments on the blog:

we focused a lot of effort in making sure that you need to write very little code to make things testable where possible.

in this case the same result can be achieved with:

//Arrange

Isolate.WhenCalled(() => HttpContext.Current.Handler).WillReturn(page);

var fakeTraceContext = ((Page)HttpContext.Current.Handler).Trace;

//act goes here

Isolate.Verify.WasCalledWithAnyArguments(() => { fakeTraceContext.Warn(null, null, null); });

//this works because all fakes are recursive with Typemock - so the trace, handler props are already fake. just use them as you with to verify calls.

Recursive fakes are very powerful:

They allow you to write less test code and still achieve the same goal.
You don’t need to set behavior on what you don’t need
Tests are more robust, because there’s less to break

And at the end of the day, remember that testability is not the issue. It’s your code – and because you’re going to live with it for a long time, make sure you design it they way you want.

Introduction to Isolation

2010-02-01T14:32:00.003+02:00

Well, it’s been a while since I’ve gone back to basics. But let’s do that, shall we? Why do we need isolation anyway? Step into my time machine, will you?

It was about 4 years ago, when I decided to try TDD (Test Driven Development). I was a project manager at the time, and I had a rule – never test anything on your team, before you try it (on) yourself. I was writing a communication server at the time, and thought – hey, why not?

Starting was easy. I added a couple of interfaces, checked that the object is created correctly. And then I got to the heart of the matter – the component used MSMQ as a messaging infrastructure. Sending a message to the queue was easy. Checking that it got there – well that’s another story.

My success for criteria for my test for sending a message was to check that the message arrived. And it arrived. Sometimes before the test ended (success) and sometimes after (failure). You see, MSMQ has a mind of its own (also known as asynchronous behavior). I couldn’t control its behavior, so I had to replace it with another object I could control. This was my first mock object.

Mocking is generally an overloaded term (that’s why I like isolation better). But at its base - it’s about changing behavior. Which behavior? Dependency behavior.

Let’s look at my class:

public class Server

{

  public void SendMessage(MessageQueue queue, object message)

  {

    queue.Send(message);

  }

}

I need to send the message to the queue. But, like I said, queue (which is the dependency of Server) sometimes behaves funny. And we don’t like funny, we like dependable. Let’s change the signature a bit:

public class Server

{

  public void SendMessage(IMessageQueue queue, object message)

  {

    queue.Send(message);

  }

}

This time, I’m not sending a MessageQueue object. Instead, I’m sending the IMessageQueue interface, which looks like this:

public interface IMessageQueue

{

   void Send(object message);

}

Now that I can inject any object implementing the IMessageQueue interface. For example, my real Message Queue object looks like this:

public class RealMessageQueue : IMessageQueue

{

  var queue = MessageQueue.Create("AnyQueue");

  public void Send(object message)

  {

    queue.Send(message);

  }

}

But another, a fake message queue object can look like this:

public class FakeMessageQueue : IMessageQueue

{

  public bool messageWasSent = false;

  public void Send(object message)

  {

    messageWasSent = true;

  }

}

As you can see, with the FakeMessageQueue, I can actually test that the message was sent:

[TestMethod]

public void Send_StringMessage_MessageWasSent()

{

  var fakeMessageQueue = new FakeMessageQueue();



  var server = new Server();

  server.SendMessage(fakeMessageQueue, "message");



  Assert.IsTrue(fakeMessageQueue.messageWasSent);

}

And that’s the whole idea behind isolation- the ability to change behavior. Today I wouldn't advise to go down the manual way – Read here why you should, nay, must use an isolation framework. But sometimes, it’s nice to go down memory lane, see how far we’ve come…

Next Drawing for the FREE Isolator 2010 This coming Wednesday February 3rd.

2010-01-31T09:54:00.001+02:00

Thank you for Following Typemock @ Twitter - we welcome you to the Easy Unit Testing Family.

You will be included in every Wednesday Drawing from now until the End of February, unless you won already or will win Before :))).

The rules are very simple:

Start following us on Twitter
To finalize your registration please Twit from your personal twitter account

Just entered to win an Isolator 2010 license to enter & keep up with latest unit testing news, follow @typemock & RT

http://bit.ly/7SVQkx

That’s it!

You may Email us your contact information to Social@typemock.com

Good Luck!!!!

.Net coding discoveries, focused on reusability: UnitTesting made easy with the power of TypeMock

2010-01-30T02:43:00.000+02:00

.Net coding discoveries, focused on reusability: UnitTesting made easy with the power of TypeMock

First Twitter Drawing….And the WINNER IS:

2010-01-28T12:34:00.002+02:00

Yesterday we did the first drawing for Typemock twitter followers. @ 1:00pm Eastern Time, The Happy Winner received an immediate notification, and gave us the permission to share his information…

The Isolator 2010 license winner is Warren Schaefer @maniacD

Everyone else is entering the next drawing on Wednesday February 3rd.

If you haven’t done so already, start following Typemock on Twitter – we promise to welcome you to the Easy Unit Testing Family.

And you will be included in every Wednesday Drawing henceforth until the end of February, unless you will win Before :))).The rules are simple:

1. Start following us on Twitter

2. Twit from your personal twitter account:

I entered to win an Isolator 2010 license To enter and keep up with the latest unit testing news, follow @typemock & RT http://bit.ly/7SVQkx

That’s it!

You may email us your contact information to Social@typemock.com

Good Luck!!!!

“This week in Testing” Episode 11 (Part 4)

2010-01-28T11:21:00.001+02:00

Is this the end? Yes. Well of this chapter anyway. We’ll have something else next week. But don’t fret – Doron and Dror still make sense.

Go watch part 4, after you do your homework on part 1, 2 and 3.

Roy Osherove on the MOSS Show

2010-01-28T09:21:00.001+02:00

Roy has been interviewed on the MOSS Show with Hilton Giesenow on unit testing, TDD, what makes good and bad tests.

Go check it out.

Register to Win Free License – First Drawing Today!!!

2010-01-27T10:00:00.001+02:00

Thank you for Following Typemock @ Twitter - we welcome you to the Easy Unit Testing Family.

You will be included in every Wednesday Drawing from now until the End of February, unless you will win Before :))).The rules are simple:

Start following us on Twitter
To finalize your registration please Twit from your personal twitter account

Just entered to win an Isolator 2010 license. to enter and keep up with latest unit testing news, follow @typemock & RT http://bit.ly/7SVQkx

That’s it!

You may Email us your contact information to Social@typemock.com

Good Luck!!!!

Free Unit Testing & how to register to our drawing

2010-01-26T18:36:00.001+02:00

In order to be part of the drawing all you need to do is to follow us on Twitter, and to Twit from your personal twitter account:

Just entered to win an Isolator 2010 license. to enter and keep up with latest unit testing news, follow @typemock & RT http://bit.ly/7SVQkx

Email your full contact information to Social@Typemock.com

We will announce the winners on Twitter, here and on FaceBook

Good Luck!

FREE EASY UNIT TESTING

2010-01-26T17:47:00.001+02:00

we are giving complimentary personal Isolator 2010 license to one of our twitter followers every week. As of today, Tuesday January 26^th until Wednesday February 24^th

Just entered to win an Isolator 2010 license. to enter and keep up with latest unit testing news, follow @typemock & RT http://bit.ly/7SVQkx

Drawing will take place every Wednesday. Typemock vendors and employees will be excluded. Spread the word….

…Israeli Dot Net User Group,

2010-01-26T14:23:00.001+02:00

Well as we promised ; we are updating the information of the second developer that won a personal license to the Isloator 2010, during the MS User group last week.

The Happy Winner is Moti Mendelovich a Team Leader in Agile Business Solutions.

For future event schedule, news and updates, please feel free to join us on Facebook or follow us here and on Twitter

Testing server-side AJAX functionality with Ivonna

2010-01-26T10:27:00.001+02:00

This is a guest post by Artem Smirnov, author of Ivonna. Ivonna is part of Isolator 2010 for web developers.

I'm implementing AJAX testing functionality in Ivonna, and would like to know your opinions.

I've implemented a possibility to test Page methods and Web services. The API is like this:

var result = session.ExecuteAjaxMethod<string>("AJAX/WebService.asmx", "HelloWorld");

The generic parameter is the return type of the method (works with custom types too). The first argument is the path, the second is the method name. As for the arguments, they are set in the optional third parameter. Currently it takes an IDictionary<string, object>, but I was thinking about an anonymous type, just like in Asp.Net MVC.

Another feature I'm planning is the UpdatePanel support. Here I'm stuck a little bit: I can simulate the correct request and obtain the correct response, but other than that, what do you usually want to test when using the UpdatePanel?

And the last question is, do you think it is worth the effort do support more advanced AJAX scenarios, such as custom controls etc? I've got a feeling that most of the hardcore TDD guys have moved to MVC, and the rest just don't need such advanced functionality.

Your opinions are welcome.

Auto Deploy Typemock Isolator

2010-01-25T15:16:00.002+02:00

In the latest Isolator version (6.0.0) we improved an old feature - The Auto deploy.
In the past you had to install the Isolator at least once on the target machine in order to auto deploy the Isolator, this is no longer needed.
All you have to do is create a folder that will include the following files:

TypeMock.dll
Typemock.ArrangeActAssert.dll
Typemock.Isolator.VisualBasic.dll
Configuration.dll
TypeMock.Configuration.exe
TypeMock.MSBuild.dll or TypeMock.NAntBuild.dll
TypeMock.MSBuild.Tasks (in case of using MSBuild)
Typemock.Interceptors.dll
typemockconfig.xml
namespaces.dat
exclude.dat
MockWeaver.dll (see below for more info)
ProfileLinker.dll (see below for more info)

Now use the TypeMockRegister task in your build script and set the AutoDeploy attribute to “true”.
This will let you run the tests with the Isolator enabled.

Example (MSBuild):

     <Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">        <PropertyGroup>            <TypeMockLocation>C:\Build\Isolator</TypeMockLocation>            <NUNIT>C:\Build\NUnit\nunit-console.exe</NUNIT>        <TestAssembly>C:\Build\Tests\Tests.dll</TestAssembly>        </PropertyGroup>          <Import Project ="$(TypeMockLocation)\TypeMock.MSBuild.Tasks"/>        <Target Name="RegisterTypeMock"> <TypeMockRegister Company ="TypeMock" License="XXX-XXX" AutoDeploy="true"/>         <TypeMockStart/>          <Exec ContinueOnError="false" Command="$(NUNIT) $(TestAssembly)"/>        <TypeMockStop Undeploy="true"/>        </Target>     </Project>

Changes in native assemblies placement

A note about placing the native assemblies (MockWeaver.dll and ProfileLinker.dll)
In the previous versions you had to place these assemblies in the same directory as the other assemblies this created extra work for users who needed to run tests in x64 and x86 machines. Those users had to copy the appropriate assemblies into the root directory before each run. This of course tend to confuse the users and lead to errors in the build script.

From version 6.0 of the Isolator this is no longer needed. You can create two directories – “x86” and “x64” under the root deployment directory and copy the native assemblies to those folders. This is the same directory structure as the standard installation of the Isolator.

The old mode is still supported for backwards compatibility so if you already have a build script that is working you don’t have to modify it.

“This week in Testing” Episode 11 (Part 3)

2010-01-25T13:15:00.001+02:00

Yes, it may look like it’s been going on forever, but it’s been only a week. Check out Dror and Doron as they roll out more testing stuff. And do yourself a favor: watch also part 1 and part 2. They’re good for you.

Watch it.

How to run NUnit tests created with VS2010 and .NET 4

2010-01-25T12:16:00.001+02:00

Today when writing tests for a new project built using VS2010 I had an interesting problem:

NUnit would not run my unit tests because the assembly that contained my unit tests was compiled using a newer version of the .NET runtime.

There are several solutions to solve this issue from downgrading my project to use earlier version of .NET to migrate my unit tests to MSTest but luckily for me no such drastic move was needed.

The new NUnit (2.5.x) have support for running tests using .NET 4 it’s just hidden inside a pile of xml.

The solution

To run .NET 4.0 test assembly add the lines below to the relevant config file, so if you’re using NUnit.exe update nunit.exe.config or if you’re using nunit-console.exe use nunit-console.exe.config – you get the point.

Under <configuration> add:
<startup><requiredRuntime version="v4.0.21006" /></startup>
Under <runtime> add:
<loadFromRemoteSources enabled="true" />

I’m using the latest VS2010 RC2 If you have a different version of Visual Studio installed change the version value to the version of the .NET 4 installed on your machine – look at C:\Windows\Microsoft.NET\Framework to find out which version you have.

That’s it!

“This Week In Testing” – Episode 11, Part 2

2010-01-21T17:35:00.001+02:00

The second in our multi-part adventure. Our brave warriors Doron and Dror discuss something something something test.

Go watch part 2 and, if you missed it, part 1.