#Nose – the unit test discovery tool

No comments

Monday, November 30, 2009

One of the benefits of programming in C#/VB.NET is amount of tools available - from Visual Studio to build servers to unit testing frameworks it seems that there is a tool for every job.

I thought that my .NET tool belt has everything I need until recently, while learning Python (actually IronPython) I’ve discovered Python-Nose (or Nose).

Nose is one of these almost trivial tools that after using it for a while it’s impossible to go without it. All it does is find all your unit tests (in multiple files) and runs them.

continuous integration is where this tool really shine – instead of running your unit testing tool of choice several times all you need to do is run the tool once and it finds all of the unit tests and runs them.

Hello #Nose

I’ve searched the web but couldn’t find a tool like Nose for C# - so I’ve decided to write one.

The new tool is called #Nose (SharpNose) and it can run unit tests written in C#/VB.NET from a specific directory:


Running #Nose

Running #Nose is simple:

  1. Configure NUnit directory (where nunit-console.exe): SharpNose.exe –config
  2. Run all unit tests in a specific directory: SharpNose.exe <target directory>

Currently #Nose only support NUnit tests – stay tuned for additional unit testing frameworks in the (near) future.

Is it free?

Yes! in fact I want you to use it – all I ask in return is your feedback.

This is a new program and it can become a cool application with your help – feel free to use email, blog comments and #Nose website for the following:

  • Feature requests
  • Bug reports
  • Let me know what you think
  • Anything else you can come up with


#Nose is hosted on CodePlex at: http://sharpnose.codeplex.com/ – download it, use it and let me know what you think.

This Week In Test Webcast

No comments

Sunday, November 29, 2009

If you’ve been reading my blog you may have noticed that I’m not above self advertisement and this post is no different.

At Typemock we’ve started a series of webcasts called “this week in test”, as you might have guessed we post a new episode each week. This is the place where two guys talk about interesting topics from blogosphere some even related to unit testing (and testing in general), software development, Agile and everything else interesting (to us).

The first three webcasts were feature Gil Zilberfeld and Roy Osherove but in the last couple webcasts I’ve been filling in for Roy - so if you want to hear me ramble about blog posts that I found annoying, amusing or just worth mentioning you should defiantly check this webcast out.


This Week In Test Webcast

RSS Feed

Is Software Development Too Complex?

No comments

Sunday, November 22, 2009

The first time I heard this question was a penal at the DotNetRocks podcast with a similar title.

My first reaction was NO! if anything software development is becoming easier. I remember back in the old days of 2003 when I scored my first programming job (at Intel) I was part of a development team that used C/C++ to develop a Linux application - boy that was hard, no Visual Studio or the other shining toys, we were elbow deep in memory leaks and navigating the code could take days. Today when I have .NET (although I still use C++ at my work) and a proper IDE I look back in horror at that time - so how could anyone claim the software development has become harder?

The panel did have a good point – because of the abundance of technologies especially inside the .NET space - WPF, WCF, WF  (WTF?), LinqToAnything and what’s not it become harder to choose what to use in a specific project. It also become very hard to be a master every technology available when a new one pops up each day.

But hey programming .NET is easy – right? it has garbage collection…
Have you counted the number of .NET languages out there? we have C# and VB.NET, we also have IronPython, IronRuby, F#, BOO, PowerShell, C++/CLI (not to confuse with Managed C++) and these are only the mainstream languages (Wikipedia has a mostly complete list).


One could claim that some of the languages above are not really new, we had Python and Ruby since the beginning of time -  true, but now I got more options when choosing the coding language I’ll use in the new project.

That’s exactly what it is options and that is good, in the past when I needed to write a website using .NET the choice was easy – ASP.NET, but developing an entire website using webforms wasn’t right for all of the projects all of the time.

ever tried to create a rich animated web UI using webforms? (is it still refreshing?). Thank god for Silverlight. Another example is ADO.NET, it’s a solid well used technology but there are places that Linq2Sql (long live) and entity framework (please don’t hit me) just make more sense (just don’t ask me when).

Today at another episode of DotNetRocks and I heard Chris Sells explain this issue perfectly – “saying that software development has become too complex is like the American complaining that they’re too fat” – his words not mine.

If it’s not clear yet I don’t think that software development has become more complex - at least not more then it used to be. a single developer these days can accomplish much more. We do not need a communication expert to send information over the internet (try it using C Sockets) and building a website or contacting the database can be done easily. So what if we have a lot of options it only means that we have more technologies to play with.

Even if you do not agree with me you can take an advice given by john Van Neumann who said “Truth is much too complicated to allow anything but approximations.” (btw if you don’t know who he is – shame on you). I remember reading that Van Neumann complained once (or more I’m not sure) that mathematics has become so diverse (and complex) that a single human being can only understand (and know) a quarter of it.

Instead of becoming a grand master of a single technology why not learn as much as possible and take what you need.

Five reasons to install Resharper 5 today

No comments

Thursday, November 12, 2009

I’ve been using R# v5 for a few weeks (ever since the nightly builds were made public) and I’m not going back. There is an exception now and then but it get caught by R# and reported back (if you want it to) without causing any problems with Visual Studio.

There are some feature I use more then others and that I really like, in fact I like them so much I want to writye about them here:

  1. It’s free
    I’m lucky - I work at a company that is willing to pay to make me more productive but in the past whenever I needed to buy a tool I needed to convince my manager, his manager, IT and whoever else that I should be allowed to spend the company’s money on that tool.
    The good thing with downloading daily beta versions is that they are free.
    Obviously everything good has to end someday and in the future this version would cost money but why not use it now and decide if it worth the cost later?
  2. External Sources
    If you ever debugged one project from within another project you know what I’m talking about:
    When you “step into” code that lives inside an assembly that belongs to some other project, if you have the assembly file symbol files you’ll be able to debug that code as well.
    Because you do not really have the source code R# used to “not work” in that file - not anymore.
    R# manages to show you all of the usages of a method, jump to the implementation and just work as if you’re in the code’s project. If symbols (pdb files) are missing R# will find them automatically (if he can) and download them from the symbol server. 
  3. Value Tracking
    This one is a time saver (from Resharper 5.0 overview page):
    ”Value Tracking gives you important information about data flow in your program. At any point in your source code, select a variable, parameter, field or property and ask ReSharper to inspect it. You will then see how its value flows through your program, back to its sources or straight to consumers. Wonder how null could be passed to a specific parameter? Track it!”
    Need I say more?
  4. Upgrade-to-LINQ
    I use R# as a Learning tool, I really like the fact that I can transform a lambda to delegate or a property to automatic property – that’s how I learnt how they should look and when to use them. With this version you can transform foreach loops to Linq statements – amazing! Right now I’m using it to refactor my old code to use Linq queries.
    Another related feature is detecting when IEnumerable can be used instead of the Lists and ArrayLists.
    If your project is not .NET 1.1 compatible you do not need to use ArrayList anymore and using List where its not needed is also a good practice especially if you do use Linq where you can.
  5. XML Formatting

    I use a lot of XML – configuration files, WPF (XAML) and what’s not, When inside Visual Studio it’s good to have the extra support that R# brings – now in this new version I can configure the XML formatter I use to make my document more “human readable” (or whatever).


Of course there is more to this new version such as Native NUnit Support (finally), Project and solution wide warnings and suggestions and ASP.NET/MVC support to name a few why not download it today and find out for yourself.

Poor developer’s performance profiler

No comments

Thursday, November 05, 2009

In the last post I wrote about a simple method that can help .NET developers micro measure the memory consumption of their application, in this post I want to show a way to measure application performance.

imageBefore I start I want to state here and now that there is no substitute to using an actual profiling application that will can find performance bottlenecks and problematic code, but if you have a small piece of code that needs profiling or you have a good idea where your problems lie then keep on reading.

For performance measuring I’m going to use old trusty System.Diagnostics.StopWatch I’ve Already talked about before. The main difference between measuring memory and performance is that when measuring performance I want to be able to know the amount of time a method inside a process took as well as the time of the whole action, in other words I need to have nested watches. Don’t worry, it’s easy.

In this solution I use three classes (no including Stopwatch):

  • ILogger – an (interface) logger to tell us how much time an action took
  • StopperManager – our starting point
  • StopperLogger – where the actual work happens (not much)

The Code

A simple logger representation:


The manager class that spawns new stoppers each time Start is called:


And finally  the StopperLogger (I’m awful with names) class – this is where the magic happens:


Each time that this class is created the current elapsed time is saved and when this class get’s disposed it uses the logger to write how much time has passed.

How to use stopper

The code that uses these classes will look something along these lines:


Running the code will write three entries in the log (or console in this case):

  1. How many milliseconds running RunPhaseOne takes
  2. How many milliseconds running RunPhaseTwo takes
  3. How much time running the whole method takes


Again I’d like to remind you that this method is good for small code snippets and cannot replace a profiling application. But if you know what part of your code to optimize or if need to add performance logging to your code so you can check how much time it take it to run on your customer machine, these classes can save you time.


Related posts:

Poor developer’s memory profiler

No comments

Tuesday, November 03, 2009

Some tools save you money.

The rule of the thumb is that if you save X days using the tool and your salary is Y dollars (or whatever you get paid with) per day then the tool is worth X times Y - it’s that simple.3D Bar Graph Meeting by lumaxart.

Over the years I’ve used several tools to do performance profiling but I’ve never quite found a good memory profiler.

Although there are some solid and effective memory profilers for .NET - they tend to run forever and the results they supply are less than optimal, using a memory profiler I could find out the type of the object that took most memory but could not find where the memory “hot spot” is (where the offending memory was allocated).

Last week while waiting for the memory profiler was taking a “snapshot” (it took two hours before I terminated it) we found a simpler way to tackle our problem, and it’s called System.GC.GetTotalMemory.

Oddly enough that method does exactly what you’d expect – return the amount of the allocated managed memory and is easy to use.

At the beginning of the code we want to measure we store the current allocated memory by calling:

long initialMemory =  System.GC.GetTotalMemory(true);

After that whenever we want to know the memory difference all we need to do is call the method again and subtract the returned value from the initial memory allocated:

long currentMemory =  System.GC.GetTotalMemory(true);

var memoryAllocated = currentMemory – initialMemory;

The parameter passed to the call tells the method to initiate garbage collection before calculating the memory size and it might cause a small delay. There is a small gotcha – using this system with multithreaded code can cause weird results but so far I haven’t noticed any.

GetTotalMemory is very useful but don’t forget that it’s not a fully fledged profiler and should only be used for profiling a small part of your code – using it to profile an entire application would be more difficult.

Related Posts Plugin for WordPress, Blogger...