Test-Driven Development of T-SQL Code - an article on using TSQLUnit to TDD the database layer. TSQLUnit is a open source framework to write tests for applications written in Transact-SQL.
Will need to investigate this technique the next time I come to create some T SQL. It’s an area (along with UI testing patterns) that I’ve been wondering about for some time. Just never had the excuse to get my hands dirty and come up with a position on it.
.. yep, managed to crash NUnit.
Or at least get it to throw an exception with one of my tests.
Not sure why yet .. no time to review the details at the moment.
In the past NCover was the tool of choice to perform .NET Test Coverage Analysis but a couple of things have occurred to change the status quo:
- NCover is no longer free,
- Microsoft offers Test Coverage in VS2008 as a free add-in. VS2008 supports a test coverage report file format that allows drill down form the report to the source code. Although their test coverage reports can only be produced from their own tests (cheers M$ .. way to go) there are ways around this if you already have, say, hundreds/thousands of NUnit tests and need that Test Coverage information.
Visual Studios handling of test coverage is great; colour coded, drill down to the source code = easy to use = more likely to use it.
I wouldn’t want to move back to NCover ever again ..
This change in how I want to work has similarities in other areas including add-ins (ReSharper) and other open source tools (NUnit) and perhaps points to a more M$ only environment for me in the future!
When you have a suite of automated tests one of the first things people start talking about (after the discussion around the amount of test code you have to write, how brittle the tests may be, etc, etc has died down) is the code coverage percentage figure.
TBH in the past these discussion to me have always been a little academic .. I mean who gives a monkeys if two developers are discussing 75% test coverage vs 80% test coverage? Or whether someone is a test coverage fascist? Or what the policy should be re: Test Coverage minimums on check in?
In the past, test coverage for me was academic for two very real reasons (and one pragmatic one):
1. I had enough on my plate just getting up to speed with TDD let alone the coverage I was getting, and
2. If you do TDD correctly you’ll automatically get good test coverage.
3. I was also using the pragmatic “if it’s painful then test it more” approach to unit testing anyway ie if some aspect of the system was particularly buggy and giving me pain then that part of the system needed to have more tests written for it.
Actually (light bulb moment!) perhaps the reason other people are more into test coverage reports than me is because they’ve come from a write first, test last perspective rather than a TDD one? If you don’t use TDD then you really can’t say whether someone has adequate tests along side source code. Interesting .. makes me look at one of my interviews I had in the past in a different light [the interviewer was more interested in test coverage than I was] .. probably says just as much about the interviewer as it does about me?
Anyway, over the last nine months I have spent much more time investigating and using test coverage reports in spite of my TDD approach because I’ve learnt that there are still good reasons to use test coverage analysis to help a developer improve their code.
Quickly, these reasons are:
- To flag missing scenarios within your tests. Typically for me this has been to do with error conditions eg exception handling. It also tends to occur when tests are more integration than unit and the code coverage analysis can help you understand where your code design is weak (from a testing perspective) and how your code could be better re-factored to improve this aspect.
- To flag issues with legacy tests. This is the big reason .. legacy code is so often without tests let alone the finer detail of having coverage issues.
- Source code issues. Typically for me this shows up as my tendency to write code that I “know” will be needed (and then never is) eg setter/getters (all the time), helper methods (less so nowadays). Also, in a similar vein, very helpful in spotting legacy code that is simply not used any more.
Climbed on Tuesday and Thursday at the Link.
Best of all though, managed to get up to Stanage on Sunday with Adrian, Rob and Katherine. Didn’t think I’d be climbing outdoors any more, let alone on grit 
Wasn’t plain sailing though: weather on the way up was horrendous .. raining and mist. Got to the crag car park at about 10:30pm and couldn’t see the bloody rocks! Could just make out a party half way up the path to the start of the crag (about 200 metres).
We walked up into the mists and moved along the crag to Balcony Buttress. Looking forward we could see the mist clearing but behind us it was still just one big cloud.
By the time we’d gotten to Balcony Buttress and picked out a couple of possible climbs I think there had been spots of rain but the mist had now completely cleared around the crag.
Now the last time I climbed on grit (start of the summer) I started on a severe and progressed onto a VS and then a HVS .. and the Severe on that day was ‘orrible. Unfortunately I seemed destined to choose rubbish grit Severe routes as the first lead of the day!
I choose Balcony Cracks S 4a *.
To cut a long story short I got totally spanked by this climb. Did not like it one bit. A big question mark over how good the friction on the rock was going to be due to the weather (the green at the start of the climb was slippery as hell), mix in bad gear placements and a horrible (for me) finish up a face using hand jams meant a very scary experience.
However the next 3 climbs went a lot smoother and I thoroughly enjoyed the rest of the day - we headed off at 4pm in glorious sunshine.
I think the next time I go climbing on grit I’m going to:
1. Do some bouldering first .. to help get me back into the grit way of doing things,
2. Have a look at placing gear low down .. to help me recalibrate my eye on grit gear placements.
3. I’d like to second someone up some HVS and above climbs .. mainly to see how they place their gear.
Powered by WordPress