RSS
Facebook
Twitter

Tuesday, December 15, 2009

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:

Wednesday, December 09, 2009

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.

Related Posts Plugin for WordPress, Blogger...