Sunday, 27 September 2009

TDD, Unit Test or nothing?

I’ve been thinking about unit testing recently prompted by a talk at .Net Developer Network, a presentation recorded at Agile 2009 and a blog post by Joel Spolsky.

Now I try hard to remain open minded about different methodologies but that doesn’t mean I won’t ask questions about them and often find that the way that the people involved who are ‘championing’ the methodology answer those questions effect my attitude towards it.

In the recent talk at .Net Developer Network given by Stephen Oakman and Ronnie Barker of the Agile workshop  they focused on using TDD, in this case Test Driven Design, to create an application but being very disciplined (strict?) and following TDD to the letter:

  • write test
  • test fails
  • write just enough code to pass test or refactor existing code.
  • test passes
  • check in to source control.
  • Repeat

Now I have no objection to that know I haven’t been doing pure TDD which has prompted me to look into it further – a good thing.

What did occur to me though is the amount of time it takes to create the code although Steve & Ronnie say you get faster as you go along I felt myself wanting to take a bigger step forward than they were doing i.e. write a bit more actual code rather than lots of small tests. 

My issue, if you like, is that the process seemed to take a very long time and although it would have been thoroughly tested it will still need to have the tester go through the code, remember “unit tests prove the correctness of the code, testing proves correctness of the functionality” but I also know what my manager would say with the increased time to finish any piece of work.

The next day Joel Spolsky blogged about ‘The Duct Tape Programmer’ which seemed to be the complete opposite of what Steve and Ronnie talked about and I can understand the desire to simply ‘code it’.  I have also recently watched a presentation by J B Rainsberger called ‘Integration tests are a scam’ which did highlight the fallacy of some of the testing we as developers do.

I think that as developers we need to use our own judgement as to what we test and whether the investment in writing tests will pay off for example should you bother writing tests for an application that consists of a single call to the database to record minimum information and has a half life of about a month?

I fully believe in unit testing this doesn’t mean pure TDD but does mean writing tests, if you can utilise the VS ‘Create unit test’ functionality’ or if you can use a tool like PEX to generate edge cases and the other tests that would take a long time to create then use it and save yourself time and be happy that your code is tested.

Friday, 25 September 2009

Asp.Net Dynamic Data – Attributes

I’ve been doing some more dynamic data and trying to work with the meta data for a table to change the display.

Previously I’ve mentioned ordering columns and although not explicitly mentioned it the hiding of columns you don’t won’t by applying the [ScaffoldColumn(true)] attribute where you set true so DD generates a column and false if you don’t want it displayed.

The attributes that I can find in relation to display of the data are:

Attribute Name Description
Scaffold Column Indicates if column should be displayed or not
DisplayName Name to be displayed in the header of the column for the property
DefaultValue Default value to use when inserting new data
Description Text to show in a tooltip when mouse hovers over the field
DataType Used to specifies the name of a type to associate with a data field to provide additional functional around that field e.g EmailAddress
UIHint Used to specify the FieldTemplate to use when rendering the column.
DisplayColumn Specifies the column to display for filters or foreign keys.  Default is to use first string column that is found

Over the next few posts I’ll being going into these attributes to show the source code and the results.

Original post