Finally, a way to preview your site in all (important) browsers

I just read this great article by Mark Voermans: Expression Web SuperPreview: Look how your site renders in various Browsers

I don’t know about you guys, but I’ve been waiting for this for a long, LONG time. I’ll give it a go this afternoon and let you know what I think…

Update
This first beta version only allows you to preview your site in different versions of Internet Explorer. We will have to wait for the full feature set until the final release of this tool…

Taken from the SuperPreview site:

This free download will allow you to compare renderings of IE6 with whatever other version of IE you have installed on your machine. If you have installed IE8, you’ll be able to compare IE6, IE8 and IE8 running in IE7 compatibility mode, side-by-side.

‘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? ;)

By |November 26th, 2007|Methodology, Test|1 Comment

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!