Rick van den Bosch - Blog

Notepad translation error?

Have a look at this article at Worse Than Failure. That's pretty funny. Or actually, pretty scary... :|

Oh and, by the way, the Rick in the article is not me ;).

Sometimes even experts mess up

Today I received a mail from Microsoft with an invitation for an Expert session. As you can see, sometimes even the experts at Microsoft let a glitch through...


(Translation of the text inside the circle: Dear sir, madam [personalize],)

My games list

Recently I put up a list of my Xbox 360 games. I'll try to keep it up to date. I must say it's difficult to choose which game to get next. There are so many good titles out! Assassins Creed, Need for Speed ProStreet, Call of Duty 4 Modern warfare, and more...

Want to join me when gaming online? My gamertag is OZGump (see my gamercard).

'100% code coverage, unless...'

When asked about my point of view about a guideline concerning code coverage, my answer always is: go for 100% code coverage. 100%, unless... Here is why.

When the guideline for code coverage is 80% (not an uncommon guideline) the devil is in the details. Or in the 20% which is not covered to be exact. When a developer 'only' needs to cover 80% of his code, you can expect him (or her) to start with the easiest scenario's, and work his way towards the more difficult scenario's until the coverage guideline has been met. This way, the scenario's which are the most difficult to realize as a test aren't hit. And, more important, the developer didn't think about the most difficult scenario's and how to test them. In that case the remaining 20% is completely unknown*. I know several testers and I can assure you: they don't like that.

In case developers need to come up with 100% code coverage, or a good reason why they can't get there (with a reasonable amount of effort), all code paths have been seen and analyzed. When a certain part if the code is not covered you can assert the risk, assess how much effort is needed to get the code coverage up to par, and make a weighed decision to do so, or not. In the last case you have an entry for the 'unless' category.

Sure, sometimes the tooling doesn't allow us to achieve a clean 100% code coverage. Visual Studio 2005 for instance sometimes skips a closing curly bracket, so you only come near the 100% for a specific method. That is one in the 'unless' category. The risk of not making the 100% has been asserted, the reason for it has been identified and a decision has been actively made.

Notes:
- You should not only look at the code coverage numbers. The quality of the asserts is pretty important too, as I mentioned earlier.
- When using [wikipedia:Test Driven Development] (strictly), these situations should be rare. Normally you start out with test cases, and then write code to make the test pass. Some even think that every line of code should add to a test case passing and that, when a line of code doesn't do so, you shouldn't have written it.


* 'Completely unknown' is a bit heavy on the drama, but it adds to the story, don't you think so? ;)

Spam frenzy

The last two weeks or so, my blog has been hit by a wave of comment spam. Every morning there are 20-something comments like 'Nice' or 'Sorry :(' to be deleted. Fairly pointless posts... The only link they contain seems to be in the URL field, and not in the message like they used to. Do they really think a blogger would see that kind of rubbish as a serious comment?

I recall Dennis posting something about filtering out one-word-comments, but I can't find the exact post. Maybe I'll just have to try playing with the spam score setting for marking comments as spam...

Project template doesn't understand AssemblyName tag?

At my current project we made a project template for Visual Studio for our testers. We added all the references, folders and files a tester needs to add a new system tests project. One of the testers (!) extended our XML generator, which generated XML testcases based on data entered in Excel, to now generate a complete C# test class. Making (system) tests which are automatically run during the nightly build now really is just as simple as entering data in Excel.

In the project template, we added a default namespace followed by $safeprojectname$ in the RootNamespace tag and in the AssemblyName tag. For example, the RootNamespace and the AssemlyName tag contain the following: Namespace.SubNamespace.$safeprojectname$. When you create a project based on the template, named TestProject, the default namespace is filled in accordingly: Namespace.SubNamespace.TestProject. The AssemblyName however, only contains TestProject.

Maybe I'm missing a step where the (entire) AssemblyName is overwritten with the $safeprojectname$ value, but if it is, why isn't that happening to the RootNamespace tag? These two fields look the same, but act differently. Today I didn't have any time to discover why this happens, but I'm going to look for the reason. And if I find anything, I'll let you know.

By the way, I'll be checking this in Visual Studio 2008 asap.

Edit 21-11-2007 @ 18:07
The MSDN forums have done their job and brought me an answer about this issue and Visual Studio 2005. There is a workaround (see link in the MSDN forums post, or click here). Unfortunately, that involved developing a Guidance Package, which we don't have time for at the moment. We already instructed our testers to copy the default namespace, and paste it as the assemblyname. That's [wikipedia:pragmatism] for you ;)

Nerd alert?

I have lots of games for my Xbox 360 I still need to / want to finish, like The Orange Box and Bioshock. And despite this, I've been working 'non-stop' behind my laptop for the last two evenings to prepare it for Visual Studio 2008, and to download and install it. It's almost time... ;)

I can't wait to get busy with the final version of Visual Studio 2008 and stuff like LINQ, extension methods, anonymous types, lambda expressions and so on. Let's do this!

010108: a new challenge

As of 01-01-2008, I'm joining Avanade. You might have heard Avanade opened an office in the south of The Netherlands the first of November. I'll be joining the ranks over there (Eindhoven!) and I am exited to get started.

I spent the past years at LogicaCMG. I had a lot of fun and, even more important, I learned a lot. I'll miss the guys (and girls!) I worked with, but I'm sure I will keep in touch with some of them. Thanks for having me. And of course: it's a small world, so we'll meet again...

This is NOT a test.

Test Driven Development is hot, just like unit testing your software and any other kinds of (automated) testing. And as we all know: sometimes stuff that's hot is misinterpreted, explained wrong or just simply used in a really bad way. Unfortunately, testing is no exception to this rule...

Not too long ago I had a discussion with a project manager who told me the code in his project had a code coverage close to 100%. Because of that, so he felt, his software would be darn close to perfect. I then asked him if testers had validated the unit tests his developers had made. The answer was no, but he didn't see the need for that because "the code coverage was so high". I'll spare you the details of the discussion, but let's say it led to a few new insights for at least one of us ;).

I'l try to make my point over here with some examples. Let's first make a very simple (trivial) method.

public static string LowercaseConcatenateStrings(string first, string second)
{
    string result;

    result = first.ToLower();
    result += second.ToLower();

    return result;
}

As you can see this is a simple method which converts both input parameters to lowercase and concatenates them. Now let's see a unittest which will result in 100% code coverage:

[TestMethod]
public void TestLowercaseConcatenate()
{
    string result = UnitTestSample.LowercaseConcatenateStrings("test1", "test2");
    Assert.IsNotNull(result, "Returnvalue is null!");
}

This unittest does result in 100% code coverage, but does not test all the scenario's applicable to the method. A null value for one of either parameters results in an unhandled exception. It doesn't even check if the value of the returned string is anything like it should be! These tests (and the code) are far from perfect, even though the coverage is 100%.

This is a simple example where it's easy to determine the flaws, but you can imagine a more complex method would require an expert's eye to ensure the quality of the asserts is up to par. A method of 20 lines with lots of calculations and object modifications, cannot be asserted with a check to see if the object merely exists.
Of course, and this should come as no surprise, testers are able to look at a piece of code or software a little bit different than developers do, so why not use their expertise. In short: check the quality of your assertions!