To the end of making my unit tests as easy to write as possible, I thought the default CodeRush template for adding a new NUNit Test Fixture to my projects could do with some tweeking, or at least customization.  Here's how I like mine:

<TestFixture> _
Public Class «Caret»«Field(ClassTests)»«BlockAnchor»
    <Test> _
    Public Sub «Field(MethodTest)»()
        «Marker»
    End Sub
End Class

My next question is, how can I make the ClassTests field default to the name of the file?

After blog mint [?]:  There are extra fields that you can insert into the template expansion, these are Text Commands and String Providers.  You get to these by right-clicking the Expansion area and choosing Text Commands or String Providers and selecting from the list.  The FileName string provider might be just what I need.

I was sitting on the train this morning with my mate Robbie, we both had laptops out, both hacking a little bit of early-morning-commute-code.  Must have looked like a right pair of nerds

Anyway, he was coding in IDL (no, not the IDL VC++ guys are use to...), no doubt doing some high science with DICOM data, and I was coding in VB.Net, so naturally the conversation drifted to languages!

I remarked that the bit I was working on was not an elegant example of VB.Net, but rather some hackage that works and will be cleaned up in a future rev.  I apologised for its lack if readability.

Rob remarked that, it was readable... but more like readable in the same way a novel is! 

I am so sorry about the title.  I am a child of a certain generation.

I deal a bit with XML in my day-to-day and "getting" XSLT was a pretty significant step forward in this for me.

Doug Tidwell's book XSLT was the key.

What prompted this revolation was seeing that XSLT was more than just a way of rendering XML to HTML in a browser, but that XML to XML translations can be exceedingly powerful.  Right now I am dealing with a data source that has been flattened from a normalized relational structure, and now it needs to be put back together into a third, different structure.  All this is do-able.

FWIW, my tool of choice currently for XSLT development is Architag's XRay... but I still prefer WMHelp's XML Pad for general day-to-day XML editing.

I thought I'd post an update from my path to continuous integration nirvana...

Today's installment is things I have learnt about writing unit tests.  Specifically I'm all about .Net and NUnit, but these are probabbly applicable in other scenarios too.

Name your unit tests correctly

What I mean to say is, name your tests as a verbose description of what the purpose of your test is. 

A good example:

<test()> _
Public Sub FooCanGenerateValidIDWhenInputValueIsNegative()

A bad example:

<test()> _
Public Sub FooSaveMethodWorks()

Can someone who dosen't code on your project (or better still, a non-coder) understand what the designed behaviour is for the Foo class from your NUnit results? 

But the most important reason is these tests must be granular and focused.  If you can't tell me what you are testing by the name of the test it is probabbly time to step back and look at the code you are testing.

Bug fixes should have a unit test

This is in two flavours:  Forwards and Backwards.

When I fix a bug, how do I know it is fixed?  How can I prove it is fixed?  Good bug reports are focused & granular.  Add steps to reproduce and now you are talking about a good bug report. 

It is also no mistake that the words focused and granular words are in this lesson too. 

Forwards:
By the time the tests are done they should describe the desired end result of the bug report.  Again there is no need to go all TDD unless you want to, but if the bug report is in the form:

An unhandled exception is thrown under some specified bad input data

then your test should show that no exception is thrown with taht bad input data.  Instant proof that the bug was fixed!

Backwards:
Looking at a closed bug report, how do I know what was done to fix the bug?
Looking at a broken build report because some unit tests failed, how do I know what bugs that code relates to so I can retest them?

The purpose of this lesson is to remove well it worked on my PC from the developers vocabulary.

Writing unit tests is a mind-space thing

While not going as far as TDD in my current projects (caution: there are TDD fanatics out there the lesson I learnt from the TDD thing is when you are writing your tests you need to put yourself in the mindspace of the client of your code.  Forget for a minute how you implemented the method and express what you aimed to do in the method with your tests.

Confession alert:  At first I thought this was a bunch of bovine compost when I read it in the Agile/unit testing/TDD echo chamber.  Then, one day, when I wasn't paying much attention, I found a bug in my code through this method as I was writing it.  Clouds parted, a little beam of sun light came down and touched my head.  All became clear.  Lay your hands on the radio, children; for we have a new believer.

Tests should be easy to write

When writing heaps of tests agains the same class or library or whatever, write a base class that does the setup etc and descend your test class from this base class as a way of making the test method only contain as little code that is not the test as possible.  This can make it easier to bang out plenty of tests. 

Or if you want to use Code Rush or Snippites in VS2k5? 
Or if you want to do absolutely anything else to make it easier to bang out unit tests?
...just do it.  There is no wrong answer.

There is no need to make this harder on yourself than it has to be!

Hows that for a long title? 

So there is a new version of Visual Studio (in CTP at time of writing) called Visual Studio Team Edition for Database Professionals - its aimed at people who might associate themselves with the title Database Professional.  I gotta say, it looks like a really good solution to some problems.

I attended a cabana session at Tech.Ed (Tech.James?) this year hosted by Greg Low on data generation in the product, and during the presentation it came up that it would be nice to have custom generator for Australian-specific data... so I thought I'd take a stab at it.

Below is a screencap of the kind of random data my generator will spit out.  Handy for columns where a check constraint may be forcing a given format for the data.  The format of the phone numbers is configurable by a property and the rows are conistant for a location so that if we generate a Vic address it will have a valid Vic phone number etc.



The good news is its really easy to do.  Even at this early stage the product has some pretty reasonable doco on what to do to write your own generators.

So my custom generator is available for download by clicking on this link

To install it on your copy of vsdbpro:

1. Copy the DLL from that zip into the following path on your PC: 
   [Program Files]\Microsoft Visual Studio 8\Common7\IDE\PrivateAssemblies\
2. Edit the config file at:
   [Program Files]\Microsoft Visual Studio 8\DBPro\Microsoft.VisualStudio.TeamSystem.Data.Extensions.xml with a suitable XML editor and add the following line:
   <type>deepdark.net.PersonalDetails, AustralianDetails, Version=1.0.0.0, Culture=neutral, PublicKeyToken=341d0bd35c6f7d28</type>
   
3. Restart Visual Studio, you should see a new generator called Personal Details in the list.
   

The source code is hardly going to start a revolutiuon, but I can make it available if there is any interest - just let me know.

This is a little creepy...

Just as Pluto gets demoted from being a planet, at work we decomission a server whose name is Pluto.

This alone means we should never use Earth as a machine name for a server.

Just a quick note...

Adobe Acrobat reader is slow... FoxIt Reader is Fast. 

Nothing in it for me, just sharing the good vibes :)  Thank you FoxIt

So I've been battling against using the Solution task in NAnt to automate the build of a large VB.Net solution that includes heaps of libraries and a web service and all sorts

I was hoping to have it done like this:

    <solution configuration="Debug"
              solutionfile="LargeProject.sln" >
      <webmap>
        <map url="http://localhost/Project/ProjectWebService/ProjectWS.vbproj"
             path="C:\Inetpub\wwwroot\Project\ProjectWebService\ProjectWS.vbproj"/>
      </webmap>
    </solution>

...but was getting lots of errors like:
error BC30002: Type 'Xml.XmlDocument' is not defined.

It turns out the source of this is all the odds and ends that VB.Net automatically includes in your project - I was only vaguely aware of them, and it seems like there is no option on the Solution task for it.

After some googling and general messing around, I added an Exec task to the build as thus:

     <exec program="C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\IDE\devenv.exe">
           <arg line="EPOnline2.0.sln /build Debug"/>
     </exec>

The down side is there is no nice output from devenv.exe like you get from the Solution & VBC tasks, but my build succeeds and that makes me happy

After blog mint [?]:  I didn't read the devenv.exe /? help close enough!  If you include /Out at the end of the command line (i.e. after /build Debug in the above example) you do get the pretty output.

This is more along the lines of the CI threads that have been occupying my thoughts of late.

I'm really impressed at the kind of technical documentation I can get from NDoc + the VBCommenter power toy, even more when it is generated and copied to my fileserver nightly as part of an NAnt script!

The next project for me on the NDoc front is to coax is to produce user documentation (rather than technical documentation) from the same sources with no extra work from me

Has anyone done this before?  Is it another case of when you are holding a hammer everything looks like a nail?

There's not much to tell since my last (vague, sleep deprived, rambling) post on continuous integartion as a development technique in .NET...

But what I have found useful is using Draco and NAnt on a VB6 project!

The problem I was looking to solve is reporting in Microsoft Visual Source Safe.  Draco.NET supports VSS, so I made an NAnt build script with one target containing no tasks and I have Draco build it every night. 

The plus is Draco includes in its post-build email the details of what checkins have happened since the last build and by who... Instant daily check-in report emailed to your door