RSS
Facebook
Twitter

Wednesday, March 24, 2010

The 3rd Israeli ALT.NET conference

  • Are you a .NET developer?
  • Are you passionate about developing better software?
  • Want to learn about new tools and practices?
  • Happen to be in Israel ?

 

If you answered the questions above with yes (or YES!) then you’re in luck because the 3rd Israeli ALT.NET is coming up around the corner – tomorrow!

 

And yes – Typemock is sponsoring this event, again.

 

If you do not know what ALT.NET is all about – you can read about it here.

We’ll meet on Thursday night (25th) to decide on the topic of the convention and then spend the next day discussing them with each other.

 

How to get there? just follow this map!

 

More details can be found on the conference Facebook page

 

See you there…




Wednesday, March 17, 2010

If you haven’t read the other posts in this trilogy - you might what to have a look at them about now:

  1. Why fake is better then mock
  2. How to create a fake object

Let’s begin the third part of this tutorial where I’ll explain what to do when we need to test that a method has been called.

The problem at hand

If you remember the code from the previous post we have UserService and we need to create a new user.

image

In the last post I’ve explained how to fake the UserRepository so it will return the value we want – this time we want to test that if the user is valid SaveUser is called.

Luckily for us that is a what Isolation (mocking) framework does well. I’ll explain how this can be done using Moq and Typemock Isolator

Verify that a call was made

Using Moq we can copy the test from the previous post and change it a bit:

  • UserExist will return false when called (line 5).
  • Verify that the method SaveUser was called (line 12).

And that’s it. Using Isolator the test will look something like this:

You might have noticed that I don’t really care what arguments are passed to the SaveUser method – for a good reason which I’ll explain about now.

Beware of verify

Now that you know how to verify that a method was called you should be aware of the issues that could happen when you misuse it.

Other then the fact that verify is very similar to Assert – it helps us check that a condition was met. And as such the same rules that effect assertions when writing tests apply to verify as well. Other then that you need to be careful of what you check in your test:

  • Don’t test that method A called method B because a simple refactor will break your test
  • Don’t test that internal (and private) method was called
  • Avoid exact arguments passed to the method unless that’s what you’re testing
  • Only one verify per test please!

As always these are only guidelines – if you write enough tests you’ll know when to follow them

Conclusion

This post is the last in my three part tutorial on how to start using fake objects when writing unit testing (at least until I find more topics to write about). Of course there is more to learn about Isolation frameworks and fake objects but I hope that this tutorial is just enough to get you started.

 

Good luck and happy coding




Thursday, March 04, 2010

Why profiler API causes my .NET application to run as STA?

It seems I’m in a tip giving mood this week. I’d like to tell a story of a bug we had in Isolator…

 

Last a user complained about a bug that prevented one of VS2010 cronies to work properly. After investigating this issue he found out that using Isolator caused this code:

[MTAThread()]
static void Main(string[] args)
{
Console.WriteLine(Thread.CurrentThread.ApartmentState.ToString());
}


To write STA on screen. It seems that running along with Isolator caused the thread apartment to transfer from MTA (Multiple Threaded Apartments) to STA (Single Threaded Apartments).Question Mark and Arrow by laurakgibbs.



 



I’d like to take a minute to thank two people:

the customer that took the time to investigate this issue and David Broman.



 



For those of you who are not familiar with the .NET profiler API – it’s a cool API that enable us developers interact with the .NET framework in a low level way (read: C++) extract information and manipulate the running .NET code. One thing it really lacks – is good documentation, in fact if you do want to use it you would probably end up reading David’s blog.



In Typemock we use the profiler API to do our “magic” of faking actual, honest-to-god .NET objects so when I saw this strange issue I concluded that it could only be cause by some bug we have in how we use the Profiler API.



After a bit of tinkering I understood one thing – I had no idea what went wrong here, perhaps it could be a VS2010/.NET 4 issue?



 



I’ve decided to sent an email to David Broman asking about this issue – perhaps I’m facing a known issue with a known fix. David’s answered my question with the following:



1. This is not a known issue



2. Send me a repro and I’ll investigate it



 



To cut a long story short I’ve wrote a simple example and David investigated it and found that we had a bug – the profiler API is a COM object and as such we’ve used CoInitialize(0)  which seemed the right thing to do at the time – unfortunately it also sets the thread apartment as well!



Because we want to application running to set the thread apartments we should not call CoInitialize from the profiler.



 



Needless to say now everything works just fine. I hope I didn’t bore you too much and that this information was helpful for at least one of you.




Wednesday, March 03, 2010

VS2010 Tip – How to run unit tests in 64bit process

One of the reason I used to prefer NUnit was that I could run my tests as x86 or x64 depending on what I needed. I was always strange that Microsoft unit testing framework didn’t have this ability.

Luckily for use it seems that Microsoft heard our pain and decided to enable us to run our unit tests in 64bit context.

And its very simple to enable – once you know it’s there.

Just head to the test configuration (yep – Local.testsettings) and under Hosts you can set if to run the tests as a 32bit or 64bit process.

image

That’s it




Tuesday, March 02, 2010

VS2010 tip: How to run unit tests in parallel

Running unit tests can take some time – at Typemock we have about 4,000 unit tests and running them takes 15 minuets. If you always wished it to take half the time (or a quarter of the time) – wait no more!

Visual Studio 2010 has a hidden feature called parallel test execution – which means that you can run four tests at the same time on your quad core.

Before you start make sure you don’t have any data collection/profiler active.

Just go to the test settings (Local.testsettings file) under Data and diagnostics and make sure that nothing is enabled.

Now for the fun part:

Right-click on the settings file (again Local.testsettings) and select “Open With…”

image

From the dialog select “XML Editor”

image

Add ParallelTestCount attribute to the Execution element. You can set a specific number of processors or use 0 to specify that the tests will run on all of the processors available.image

Don’t forget to save the file.

You’ll need to close and re-opne the solution in order for the changes to load.

You’ll need to manually set parallel test count each time you update the settings through the UI – because Visual Studio rewrite the file each time the settings are changed.

 

Hopefully by the time Visual Studio 2010 will be officially released we can activate this feature from the test configuration UI and won’t need to mess with XML.




Related Posts Plugin for WordPress, Blogger...