ISerializable - Roy Osherove's Blog

SilverUnit 0.5 has been released with some speed optimizations, as well as binary reference to the latest Typemock version 5.3.0.

If you don’t know what it is, SilverUnit aims to allow true unit testing of silverlight objects, without needing to run them in the silverlight runtime or in the browser. It’s for testing only logic, and it’s much simpler to use that Microsoft’s silverlight test framework (which is essentially an integration test framework).

Project Template

If you’ve been working with SilverUnit, you know it’s a pain to setup a “regular” test project that will reference a silverlight project under test. So I followed Jamie’s footsteps and created a Project template installer for SilverUnit. (Unlike jamie’s installer, this one create a regular class library project with regular references to silverlight assemblies)

After installation, you get this nice template in the new project dialog:

this template should contain all the relevant references to start testing your project with SilverUnit (you might need to remove and re-add the reference to the typemock.dll)

you can get it in the latest release of CThru and SilverUnit on Codeplex (0.5 at the moment):

This question keeps coming up: “How can I test that an event was actually raised from my class under test?”

actually, there is an easy way to check if an event was raised.
you subscribe to the event in your test, and in the event handler you set a boolean flag to true. then you just assert on the flag.
here is a quick example:

Code:

public void Test()
{
bool wasRaised=false;
var button = new Button;
button.Click += ()=> wasRaised=true;
button.DoSomethingThatShouldHaveTriggeredTheEvent();
Assert.IsTrue(wasRaised);
}

If you feel less comfortable using lambdas:

public void Test()
{
bool wasRaised=false;
var button = new Button;
button.Click += delegate

{

wasRaised=true

};

button.DoSomethingThatShouldHaveTriggeredTheEvent();
Assert.IsTrue(wasRaised);
}

Unfortunately, with VB.NET’s current version, doing this in a single method is next to impossible, so you are forced to register to the event with a method at the class level, and check that:

Code (VB.NET):

public sub test()

wasRaised=false
dim button = new Button()
AddHandler( button.Click , AddressOf(OnClick))

button.DoSomethingThatShouldHaveTriggeredTheEvent()
Assert.IsTrue(wasRaised);

end sub

public sub OnClick(source as object,e as EventArgs)

wasRaised=true

end sub

Oh, didn’t I mention we can now fake DateTime.Now in unit tests?

The time has actually come. After 2.5 years, and two kids, my book is finally done and is available in full form as an EBook. at the end of the month it will be in print form. Now would be the time to get it, when it is still at a “pre-order” pricing. Get the preorder price either at Manning(along with the EBook) or at the amazon page.

I love the cover image. How about we call this “The Samurai book” from now on?

This is the book that I wished I had when I started out writing my first tests, and that combines my knowledge about unit testing from the past 5-6 years or so working with companies on real projects (and real failures).

It contains things I have not seen in other places – writing readable, maintainable and trustworthy tests, as well as guidelines on how to review someone else’s tests and what to watch out for.

I was lucky to have the foreword written by no other than Michael-Legacy-Code-Feathers himself, and with some great quotes including one from Kent Beck about the book.

Here is the Table of Contents.

Free Chapters

The book comes with two free chapters:

Chapter 1 – The basics of unit testing(PDF)

Chapter 3 – Using Stubs to Break Dependencies (PDF)

Or get the full book

Book description:

Unit testing, done right, can mean the difference between a failed project and a successful one, between a maintainable code base and a code base that no one dares touch, and between getting home at 2 AM or getting home in time for dinner, even before a release deadline.

The Art of Unit Testing builds on top of what's already been written about this important topic. It guides you step by step from simple tests to tests that are maintainable, readable, and trustworthy. It covers advanced subjects like mocks, stubs, and frameworks such as Typemock Isolator and Rhino Mocks. And you'll learn about advanced test patterns and organization, working with legacy code and even untestable code. The book discusses tools you need when testing databases and other technologies. It's written for .NET developers but others will also benefit from this book.

What’s inside:

• Test Review Guidelines
• How to create readable, maintainable, trustworthy tests
• Stubs, mock objects, and automated frameworks
• Working with .NET tools, including NUnit, Rhino Mocks and Typemock Isolator

I’m proud to announce the official release of Typemock Racer- A Parallel Inspection engine for your multithreaded code. Think Microsoft Chess, only it’s available today, for visual studio 2008, and will continually be updated with new features.

Racer’s main purpose is to find and recreate deadlocks in code that you give it. Think of it like specifying a unit test, but then putting one simple attribute on top of the test called [ParallelInspection]. This will turn the test into a Racer test.

In the future racer will extend to also checking for race conditions, but currently will find deadlocks in managed code.

I made a quick little movie that shows how to start using it quickly and painlessly. see below.

Thanks to Andrew Woodward for this great intro to TDD with SharePoint!

this awe inspiring movie is the reason I got into TDD in the first place.

Video is courtesy of the Sharepoint Pod Show – if you’re into SharePoint, looks like that podcast should be missed!

 <a href="http://video.msn.com/?mkt=en-US&amp;playlist=videoByUuids:uuids:e4f7de58-89b1-43ee-af89-2c90fad21392&amp;showPlaylist=true&amp;from=msnvideo" target="_new" title="Test Driven Development - Part 3">Video: Test Driven Development - Part 3</a>

as a personal reference – next time I need FinalBuilder to output data into TeamCIty (such as current build status etc..) :

here is the documentation that explains the simple text formatting rules

All you need to do in FB is to use “Comment” tasks and output the text you need based on these rules into the console.

TeamCity will pick them up automatically.

of course, this will also work with all other custom runners you might be building for TeamCity

My company is giving away free Typemock Isolator licenses for bloggers, in light of a new ASP.NET Unit testing bundle offering.

If you’re interested in all the gory details, this is the place you want to go.

I first heard about the book “Code Leader” from this blog entry. What got me interested about it is that this is the first book I‘ve seen that tries to take the technical approach to teaching team leadership.

First, I think that this book is (at least from the table of contents) very much something that is missing in today’s book landscape – a book that talks about best practices and things that “work” without trying to be too “agile” driven. What I’d call “a book for the rest of us”.

But, as I looked at the Table of contents for the book, I tried to find something very specific that anyone talking about code leaders should be talking about.

Can you tell me what it is I was not finding in the TOC?

Chapter 1 (Buy, not Build) describes how to go about deciding which parts of your software project you need to write yourself and which parts you may be able to purchase or otherwise leverage from someplace else. In order to keep costs down and focus on your real competitive advantage, it is necessary to write only those parts of your application that you really need to.

Chapter 2 (Test-Driven Development) examines the Test-Driven Development (or Test-Driven Design) philosophy and some practical ways of applying it to your development lifecycle to produce higher-quality code in less time.

Chapter 3 (Continuous Integration) explores the Continuous Integration philosophy and how you can apply it to your project. CI involves automating your build and unit testing processes to give developers a shorter feedback cycle about changes that they make to the project. A shorter feedback cycle makes it easier for developers to work together as a team and at a higher level of productivity.

Chapter 4 (Done Is Done) contains suggestions for defining what it means for a developer to “finish” a development task. Creating a “done is done” policy for your team can make it easier for developers to work together, and easier for developers and testers to work together. If everyone on your team follows the same set of steps to complete each task, then development will be more predictable and of a higher quality.

Chapter 5 (Testing) presents some concrete suggestions for how to create tests, how to run them, and how to organize them to make them easier to run, easier to measure, and more useful to developers and to testers. Included are sections on what code coverage means and how to measure it effectively, how to organize your tests by type, and how to automate your testing processes to get the most benefit from them.

Chapter 6 (Source Control) explains techniques for using your source control system more effectively so that it is easier for developers to work together on the same project, and easier to correlate changes in source control with physical software binaries and with defect or issue reports in your tracking system.

Chapter 7 (Static Analysis) examines what static analysis is, what information it can provide, and how it can improve the quality and maintainability of your projects.

Chapter 8 (Contract, Contract, Contract!) tackles programming by contract and how that can make your code easier for developers to understand and to use. Programming by contract can also make your application easier (and therefore less expensive) to maintain and support.

Chapter 9 (Limiting Dependencies) focuses on techniques for limiting how dependent each part of your application is upon the others. Limiting dependencies can lead to software that is easier to make changes to and cheaper to maintain as well as easier to deploy and test.

Chapter 10 (The Model-View-Presenter Model) offers a brief descr...

--------------

can you tell what’s missing here?

Yes. these are all great subjects, but how can a book presume to talk about code leadership without having a chapter on, well, leadership?

• What makes a good team lead a great team lead?
• how does a team lead deal with personal issues in the team?
• People not working well with one another
• One developer that is slowing down the whole team
• How do you “grow” a team of great devlopers?
• What are the common pitfalls that team leads fall into time and time again?

These things are essential. To understand why, just think that even if you are a team lead who knows everything in this book, it does not matter if you cannot get your devs to do it right. it does not matter if you cannot find the inner strength to face a developer who is not up to par and get him up to par.

I hope I am mistaken and that somewhere in the book these ideas and more are addressed, but it does not look like it from the chapters. Instead, the book takes the easy road which is just talking technical. To me, a code leader is not just a technical beast. he or she needs to be so much more than that to make an OK team into a great team.

It does not matter one bit how good you are technically if you can’t drive the team.

I’ll start talking about what I think makes a good team lead in upcoming posts.

Trying to balance work life and … life… is challenging. I’ve taken quite a bit of a vacation from speaking engagements, but starting June I’m back to some of my old antics. Here’s my travel schedule if you care enough:

• Vienna, June 16: I will be doing the Keynote session as well as three other sessions on the first day of the Software Engineering Conference in Vienna. Topics include: 10 ways agile adoption can fail, tips and tricks for dev teams, unit testing best practices and understanding TDD (intro). My guitar will accompany me.
• Oslo, June 17-18-19: I will be doing a full day of talks at the awesome NDC, mostly about TDD, unit testing with mock objects, and such, but also will talk deeply about CThru and Silverlight unit testing. My guitar will accompany me.
• Oslo, August 24-28: I will be doing the 5 day Test Driven Development in .NET master class  in Oslo, Norway.