I'm currently using MSTest in my day to day work and I'm not always writing true unit tests but occasionally I'm also writing what I call integration tests. That is tests that uses a real database and/or web service. As such these integration tests are fragile and might fail because of the configuration on the machine running the tests or just because a service is temporarily down. Getting a test failure because of this is annoying and you really want to make sure that whoever sees the failure knows an occasional failure may be "OK". So in order to signal that the test didn't really fail but was unable to run as expected and intended I use Assert.Inconclusive. Basically if I'm relying on a web service I ping it if there is a failure. if the ping also fails I'll use Assert.Inconclusive to signal that the test can be ignored in the test run.
I got a comment here that deserved more than just a comment response. It is an interesting comment and I wish I could sit down with whoever wrote that and discuss that comment. But I guess that will never happen so here it goes. First of all I feel sorry for whoever made that comment and everybody else that have had a bad experience with Scrum. Scrum is by far the most abused and misused agile practice there is out there I think. Way too many organizations have tried to implement Scrum "because it makes all projects successful" without knowing what they're getting themselves into. Scrum is a tool that may kick-start a team into being more agile. But the team has to be open to embrace agile rather than scrum. Teams can be very agile without scrum. A very good team can probably be agile with a waterfall type of process too. Scrum has a tendency to focus on sprints and planning while the most important concept is hidden in the retrospect; the ability (and will) to improve the team's productivity. A team that is "happy with how things are" will in my opinion sooner or later experience an utter failure or just be unhappy. A team that continuously looks for ways to improve will more likely avoid big failures but more importantly; everybody on the team will be much more happy.
The second part of the comment intrigues me. I agree that most of the bad attempts at implementing Scrum have been initiated by managers. But I think that is just bad copy cats... And I've seen Scrum being used for an excuse to micro manage. That does not make it right nor does it make Scrum beign a nice experience for anybody involved. All good implementations I've seen however have typically started with a team that decides they want to improve their situation and then supported by management since good management will see (or already knows) that happy teams are productive teams and micromanagement doesn't make anybody happy.
One thing that I'm still wondering is; if you're a person who have been forced to try Scrum and it didn't work out well; what would you like to do? What does your perfect way of working look like?
So while this is merely more than a long comment I would like to recommend some reading:
Time for my 2010 according to this blog's statistics. As last year we'll start of with the five most read posts:
Apparently code coverage for c code (which was top one last year too) is still interesting.This year that post alone had almost double the views as the front page itself. Top ten search terms to land on this blog (2009 ranking within parentheses):