Helper Code

Links: Being Successful with Agile and unit testing

It is always nice to hear when a fellow developer succeeds and what makes these posts even better is the fact that they also contain valuable tips as well.

Lessons learned from an Agile project (David Tchepak):

Dave^2 writes about an agile project he’s been part of for the last 18 months - and he has a lot to tell you about it. They’ve been doing XP and Scrum using 2 week iterations and as far as the post goes it was great.

The post explains about several points that attributed to the project success:

• Short user stories
• Momentum
• Feedback
• Acceptance testing
• Do what works
• End-to-End as fat as possible

But don’t take my word for it – read about it in his blog.

Six Months Down The Line – Unit Testing (Isaac Abraham)

Isaac project is getting close to its first release and after six months of practicing TDD (Test Driven Development) – he has some insights on unit testing and how to make them work for you.

This is the first project he’s been using TDD and unit testing all the way and as far as I can tell from the post it went great -no trivial task.

He has a few tips on how to succeed with unit testing such as “keep your test as granular as possible” and “keep your compile time down”.

The post has a nice overview of the tools used (MSTest, Rhino-Mocks) along with Isaac’s experience with them.

All in all a good post to read if you’re interested in reading the lessons learnt from a successful TDD first timer.

How to collect NUnit test results in TeamCity

I’ve been using TeamCity for some time now and I love it - It’s easy to install and use. TeamCity can also run unit tests using several test frameworks and collects data about the tests runs as long as you’re using one of the supported build scripts (e.c. NAnt or MSBuild) – from how many tests have been run to a list of problematic unit tests that tend to fail.

All of this is nice and dandy but what if you happen to use a different build script tool – one that doesn’t have TeamCity integration?

At Typemock we use FinalBuilder to create our build scripts – we run it using TeamCity “Command Line” runner by calling an executable that runs the script. The problem with this method is that TeamCity does not collect the test run information automatically – or does it?

On a closer look at the runner tab on the build configuration you’ll find this:

That’s right – TeamCity can load data from the last run – and it has support for NUnit xml report.

All is left is to configure NUnit to output the test result at the end of the run – Simple.

Tip #2

If you need to write messages from FinalBuilder just add the following JavaScript command: Action.SendLogMessage("Hello World!",stInformation) – found via StackOverflow

Happy coding

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

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.

1. Under <configuration> add:
   <startup><requiredRuntime version="v4.0.21006" /></startup>
2. 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!

Seesmic look – the twitter client for your mom

I use twitter quite a lot and I’m always on the lookup for a new way to read it’s almost endless stream of data. Today I’ve found a new and interesting client from the people who brought the first window native twitter client – Seesmic.

Seesmic look takes a new approach to showing twitter and it’s intended for users who do not use twitter and would likely be intimidated by the amount of twits and – in fact hey aiming on introducing twitter to less technology swavvy crowd:

It's not just for your typical Seesmic user with an online presence, but something you may want to introduce to your non-Twitter friends or family. Go ahead and show it to them and see what they say. With Look, we hope you're able to show them and better explain what Twitter is all about - even train them about social media.

It is also a great example of what can be done using WPF:

Beautiful!

Have a go – download it here and try and introduce twitter to your friends and family

Real world unit testing presentation

If you the Israel .NET Developers User Group (IDNDUG) and you’d like to learn more about unit testing you can view my presentation here.

I talked about unit tests and how to write good unit tests in the first session. I had a lot of fun and I hope that so did my audience.

Additional resources

During the break and after the 2nd session (done by Gil Zilberfeld) some of the participants asked what addtioanl resources are available for developers who want to learn more about unit testing – so here they are:

• The art of unit testing – this book written by Roy Osherove explains everything about unit testing and how to do them right.
• This Week In Test webcast – Where we talk about testing, agile and anything else that we find interesting.
• Typemock Insiders blog – The blog about unit tests and mocks (fakes!) and if course Typemock Isolator.

Why you want to be a Polyglot programmer

Polyglot programming defined

From Wikipedia:

Polyglot (person), someone who aptly and with a high level of fluency uses many languages. The word derives from the Ancient Greek πολύγλωττος (poluglōttos, “'many-tongued, polyglot'”), from πολύς (polus, “many”) + γλῶττα (glōtta, “'tongue, language'”)

The term was (probably) coined by Niel Ford in his blog post Polyglot Programming (from 2006) – or not have a look at We Aren’t Too Stupid for Polyglot Programming for more details (Robert Fischer).

Simply put (because it’s all Greek to me) – Polyglot programmer is a programmer that know several programming languages. So Polyglot programming is using several languages in the same project.

Is Polyglot programming a good thing?

Using multiple languages in the same project can be a hassle – I have been at a company that had both C# as well as VB.NET used in the same project without any good reason other then the fact that it was maintained by two developers, one preferred C# and the other VB.NET.

At the end the company decided to work only in one of these to make the code more usable and maintainable.

So is using multiple languages in a project a bad thing – not necessarily, in fact you might be doing it right now:

Do you used a database? RegEx? what about XML? although these are not “classic” programming languages they have domain specific languages that you use to make them work. Many developers use some scripting language to administer their machine or for the project build process – one could argue that that is part of the project as well.

In fact when thinking about all the project I was part of I can’t think of a single project that had only one programming language involved in it’s creation – my favorite is using C# along with C++ for low level programming.

The .NET framework provides a good platform for multi-language programming but that concept is not new. C, Python, PHP, Java are just a few languages that can used in a Polyglot project.

The Polyglot programmer

Do a developer today can make do with learning a single language (e.g. Java, C#, C++) and using it throughout his career? It is a possible (although improbable) scenario.

If all of your projects require only one language do you really need to learn additional languages? I think so…

The first reason to learning additional programming languages are the tools of our trade and learning more languages mean you have more tools to choose from.

The second reason is that by learning different languages we actually learn different ways to think about the problems we’re solving in our everyday work. I know that learning dynamic language helped me become a better C# developer.

Conclusion

Nowadays it’s almost impossible to do your work without constantly learning new technologies. You do not want to be that guy who gets to a point at the project and stops because he do not know XYZ.

My suggestion to you is to make a new year resolution – learn a new programming language.

Related reading:

• Polyglot Programming 
• We Aren’t Too Stupid for Polyglot Programming
• We need more polyglot programmers

Two (and a half) development links from the past

There are quite a few link blogs out there, like Alvin Ashcraft's Morning Dew, The Morning Brew and Tech Tweets. These sites help to stay on the bleeding edge by providing new links daily.

Perhaps I’m getting nostalgic because of the new year, instead of posting links from the last week I’d like to post two links from the past:

Two links

We will not ship *** (Robert C. Martin) – a blast from 2003 that is still relevant today and would probably be relevant as long as software is being written. This article explains how we sometime fail to produce a quality software while blindly following rules. He talks about how the rules of our trade can be broken as long as we are responsible to provide value and create high quality product.

If you have a team member (or manager) who insist of doing something just because it’s “best practice” or because the team is committed to follow XYZ methodology. Ask him if it help provide value to the product and let him read this article.

50 in 50 (Richard P. Gabriel and Guy L. Steele) – One of the funniest session I ever seen from the JAOO 2008 convention. This is a brief overview of 50 years of computer science and programming languages – especially the weird and less known languages such as Ook! and Shakespeare.

As well as being hilarious this presentation is also a good resource of the history of computer programming.

And a half

Eternal Flame is used in the 50 in 50 presentation, just to remind us what programming is all about ;)

I was taught assembler
in my second year of school.
It's kinda like construction work —
with a toothpick for a tool.
So when I made my senior year,
I threw my code away,
And learned the way to program
that I still prefer today.

Happy new year

How to unit test “un-testable” code (in a nutshell)

Not being able to unit test an essential scenario is one of the reasons developers stop unit testing their code. In fact most of the time when a team decides not to use TDD (Test Driven Development) is because it seems as if they won’t be able to test the production code using unit tests.

Most of the time this is just wrong!

Of course some scenarios are more difficult to test but in most of them it’s not impossible, just a matter of technique and tools.

First – understand the problem

Unit tests are small, atomic pieces of code that test a single functional unit. The scenario might be difficult to unit test because you’re trying to test too many things at once or because you’re testing to wrong thing.

Not every part of the functionality should be tested – When developing a client component that uses webservices to communicate with a server, there is no reason to test that WCF works. Instead test that your code calls the webservice and act according to the returned response (two separate tests - please).

Try answering three questions in order to decide if the you’re testing the right functionality:

1. What method am I testing?
2. What scenario am I testing?
3. What is the expected result?

If the answer of the three questions above took more then one (short) sentence – you might be trying to test too much. In that case - break the test to several smaller tests and try again.

In the end you may find some outer dependency that hinder your ability to test your scenario in order to unit test that code you’ll need to isolate your code from that external dependency.

Design for testability

I’m not a big fan of design for testability, I am a huge fan of good design. Some practices of good design also create a more testable code (e.g. code to interface not implementation) and should be used to make the overall development process easier.

I found that the easiest way to design testable code is to write the tests first – TDD style.

Use dependency injection if it make sense in your production code and follow the principles of good design and your code will be more testable but don’t overdo it – design your code for maintainability not for testability.

Refactor for testability

Requirements changed or you’re writing unit tests for code that was already written and suddenly you discover that some external dependency (e.g. Database, 3rd party tool etc.) prevent you from writing your test.

No problem - because your code is in fact your code you can change it to make it more testable.

Refactor a class constructor to receive additional parameters or add an internal property to replace the external dependency with a dummy class.

Isolation Framework (yes - Mocks)

Isolation frameworks were created so you won’t have to write additional code (or change your existing code too much). They create fake objects and set their behavior and some can even set behavior on existing objects (and even these “evil” static methods).

In a nutshell fake objects help you isolate your code from external dependencies without the need to write a bunch of dummy classes.

Use Integration tests

There comes a time when it’s no possible to unit test a scenario but before you give up there is one other alternative - Integration tests.

Instead of testing a specific isolated part of your system – why not test system wide functionality?

You’ll probably need and might need setup (and teardown) but you’ll end up with an automated test just as well.

Conclusion

In the vast world of software development there is still code which you could not unit test but I hope that I managed to convince you that most of your code (if not all of it) is testable, sometime writing unit tests is another problem that you need to solve as part of your work.

In future posts I hope to cover each of solution above and how they can be used when writing unit tests.

Related links:

• Design for testability (presentation)
• Patterns in Practice - Design For Testability
• DI Patterns: Constructor Injection
• List of mock object frameworks (Wikipedia)
• Integration testing (Wikipedia)

Book Review: WPF in Action with Visual Studio 2008

Introduction

I was a bit worried when I first saw this book title – using visual studio version seems a bit over specified for my taste, reading the sub title made me even queasier - It looked as if the book will become obsolete in just a few months when VS2010 will be released. Today after reading WPF in Action I know that I will keep using it as a reference for many more years.

This book is good for WPF beginners that want to learn how to make beautiful (and cool) user interface (UI) as well as more advanced programmers that need to be reminded how to create a specific effect.

I especially liked the casual tone the authors use along with funny (geeky) jokes and anecdotes, this book feels more as if the authors are having an informal conversation with you then a technical book.

This book explain why things were created the way they are when possible or explain why the alternative is much worse in some cases.

WPF in Action’s 520 pages cover as much of WPF as humanly possible, although I think that more information about using blend is missing, but then one could argue that it would make the book so heavy that you might loose a toe if the book fell on it. Besides this book title suggests that it would be centered on VS2008 and not expression blend.

The book is divided into four parts that gradually bring you up to speed with WPF development (with VS2008 :) ).

Part 1 - Past, present, and future

This part begins with a bit of history – about windows API, MFC and webforms and how they evolved into WPF. Although this chapter is not crucial it’s a good summery of windows UI development.

Next we have the inevitable “hello world” application – at least it seems that the authors detest “hello world” examples as much as I do. After that there is a short explanation about the development environment (you guessed it VS2008) and a short overview of WPF (WPF from 723 feet).

Part 2 - The basics

This part we get to see WPF in action. While creating a calculator application we’re introduced to the layout system, events, styles, templates and the new way property behave in WPF. After reading this chapter you can start writing your first WPF based UI. Part 2 ends with the cool chapter 8 that gives a glimpse to how WPF can be used to create really cool controls and effects (as well as a working calculator).

Part 3 – Application development

After we’ve finished the simple calculator in the previous part this part shows how to create applications with complex UI layout start with a Wiki. Commands and routing are introduced as well as the all powerful data binding.

From there we continue to template, valuators and the M-V-VM Uber-pattern.

I guess because data binding while important can be a bit boring this part ends with three chapters about custom controls (make me a button with animation on it), and drawing (2D and 3D) that shows exactly where WPF “shines”.

Part 4 – The last mile

This is where the “advanced topics” are – navigation application, WPF and Silverlight and printing to name a few.

I especially liked the chapters about transition effects – because in my opinion this is what WPF is all about.

The last two chapters are about interoperability and threading – two “real world” necessities that I’m glad that the authors found important enough to cover in this book.

Conclusion

Finding a good book to learn the huge topic of WPF is no simple task, while many books on the subject insist on showing you how things look in both XAML and code WPF in action prefers to show you how to do a specific job.

As a past MFC to winforms developers I enjoyed reading about the WPF internals that are explained throughout this book.

If you’re a .NET developer new to the WPF world looking for a good book I recommend you read it. I know that although I’ve finished this book I’m still using it as a reference daily.

#Nose – the unit test discovery tool

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

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.

Links:

This Week In Test Webcast

RSS Feed

Blog maintenance - test post

This is a test post – sorry…

AWHDYSDGCWT5

Is Software Development Too Complex?

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

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

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.

Before 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

Conclusion

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
• Performance Tuning in .NET using Stopwatch
• How does Stopwatch work
• Performance optimization tip – understand your memory layout