Dave Snowden has just posted a chain email to the Cynefin Yahoo Group. Mmm, person behind a framework concerned with “Narrative” and the spreading of stories posts chain email……………

Just been reading the Creating Passionate User Blog. Interesting stuff, living within the intersections of marketing, business, and programming. And talking of user interfaces, this is definitely worth a look; try the computer sales demo.

In this post below I listed various advantages\disadvantages of Black Box vs Database Checking approaches to testing that data has been saved to the database. I didn’t really come to any firm conclusion: I did still have a feeling that checking the database contents would give me more confidence than the Black Box approach, regardless of the reasons listed in that post.

I’ve just realised the reason for my preference is that I do not think of the database as persisting my domain objects: I think of my domain objects as representing the database. As the database is dominant to me, it is natural that I concentrate my testing on the database.

There are various reasons for this, to do with my background and experience. I think it is what Dave Snowden would term “expert entrainment”. Disrupting this particular pattern will, hopefully, open my mind to more ideas.

Wow! Google suggest is impressive! Doesn’t look much at first, but try typing a search. (Found via Joel on Software). This raises the bar for web interfaces: don’t show your users ;-).

Andy Swan has set me thinking about database test strategies. I’ve been following the same general strategy for a few years now; it is handy not to have to think about the meta issues, and concentrate on the task in hand, but every now and again it is good to have a rethink.

Andy is arguing for a “black box” approach to the database testing. Rather than fall for the fallacy of best practice by arguing one approach over another, I’ll try and consider the advantages, disadvantages, and applicability of different approaches. I will ignore another approach, mocking the database, for the moment (except for saying that I agree with Andy that it is not usually a good idea).

I’ll just steal the examples from Andy’s blog entry.

Black Box

public void testAdd()

{

  Expenses e = new Expenses();

  assertEquals( 0, e.getNumEnties() );

  e.add( “description”, “23.50” );

Expenses other = new Expenses();
assertEquals( 1, other.getNumEntries() );
}

public void testAdd()

{

  Expenses e = new Expenses();

  e.add( “description”, “23.50” );

  // check database table has been updated

}

Advantages of Black Box over Checking Database Contents

An obvious advantage of the Black Box approach is that it is, by definition, implementation independent. You can change the table name and field names without changing the test. You could even decide to change the persistence mechanism to the file system or LDAP or Object database without changing the test.

Another advantage is the you do not need to access the database in your test code. Even with testing data access code, this adds an additional level of complexity to the Check Database Contents approach.

Advantages of Checking Database Contents

Not everything that goes in always comes out – it is quite usual for data to be written to the database that are never read by the application. This could be audit data, or data used for MIS reporting; this could consist of entire tables or housekeeping columns; you’ll need to read it to test the write.

Conversely, not everything that comes out goes in – it is even more common for data to be read by the application that are written by something else, for example user security details; something will need to write the data to test the read.

Some direct database access will often be needed for tearing down the tests: delete requirements are rarer than create, read and update; it is very rare for production code to require a delete all my data method.

With Black Box, you need to code more before you get to green – you need to write both the read and write code before your code gets to green. Also you have more code to search for bugs – if the test fails it could be in the read or the write.

Conclusion
I may have been too dogmatic in always taking the Check The Database approach when writing to a database. The appeal of The Black Box approach is its simplicity; my experience is that the database structure changes more rarely than the code and when it does the domain model needs to change anyway. What put me off Black Box is my preference for keeping the amount of code being exercised by a single test small.

I will probably give the The Black Box approach a try, bearing in mind that it is only applicable when there is symmetry between reads and writes.

http://matt.blogs.it/stories/2004/03/15/daveSnowdenCynefinDynamics.html
http://www.kwork.org/Stars/snowden_part1.html
http://www.waterweb.org/wis/wis6/papers/Snowden_03_1.pdf

On encountering a new programming “technology” my initial reaction is usually puzzlement: I can not see the point. Often I then notice some area in which it provides a cleaner solution, and I begin to see the light. With Aspect Oriented Programming it was declarative transaction handling and logging.

I have been having trouble seeing the point of Domain Specific Languages, as highlighted in Sergey Dmitriev’s Language Oriented Programming article. I was not convinced that a well defined Obejct Oriented model would be significantly less expresive than a DSL; in fact in I’m still not so sure, but – thanks to a conversation with Andy Swan – I am beginning to see applications for pluggable DSLs.

A good example is database access within a Java (or other) program. It would be much neater to plug a syntax checked SQL language extension into the data access parts of program than any of the options currently open to us. Imagine if you could write the following:

public void updateDescription(int id, String newDescription)

{

UPDATE mytable SET description={newDescription} WHERE id={id};

}

Replacing embedded languages with DSLs is hardly the revolution that Sergey seems to be describing. It is, however, a starting point from which to explore the idea.

Jmock uses functions with side-effects to build complex expressions. The following tells the mockSingleCustomerCreatorFactory to expect the method create to be called once with the parameters “mendel” and 28; it should return the mockCustomer object:

mockSingleCustomerCreatorFactory.expects(once()).method(“create”)

.with(eq(“mendel”), eq(28)).will(returnValue(mockCustomer));

I found an article (of sorts) by David Snowden, who gave a key note at XP Day (see my notes here). The concluding sentences are equally applicable to Agile frameworks (eg XP and Scrum):

It will not do to confuse something which is simple, but requires profound understanding with something that it just easy to do and provides a quick hit. Simple but not simplistic, an art not a science but above all a profoundly human technique that rejects the mechanical and authoritarian practice of too many management scientists and consultants.

I’ve recently started to attend Extreme Wednesday sessions in the Filmhouse Cafe on Wednesdays. When I got back home after last night’s session, Jenny asked how was the “Nerd Club Meeting”. Well this is how it went.

We had two separate goes at a simple web app to record expenses and payments, based on the spreadsheet I use to track my expenses. There were two pairs: Abdel and Jordon, Andy and I. Colin and John joined later.

Getting started – Story Independence
Trying to define the stories and acceptance tests was a useful exercise. We had trouble defining tests for “action” stories (eg add expense) without any view stories to verify the action had taken place: we combined an action and view story to get started. Ok, that seems obvious now but I really need to try these things to get a feel for them – reading books (eg Mike Cohn’s) is not enough.

Upfront Design vs The Simplest thing and Emergent Design
Abdel and Jordon invested a small amount of time in defining a domain model. Andy and I had decided to go for what we thought was the simplest thing: a service that interacts directly with the database.

We didn’t get that for, through spending too much time discussing other things (Andy is so knowlegeable that it’d be a waste not to). Although by the end of the session we both thought our approach was the best – I’ve changed my mind. We were concentrating on an “enter” action: by the time we’d got to the “query” actions we would have probably needed to introduce some kind of DTO or swap to a domain model; the “simplest thing” was probably (in the end) a domain model.

It’s dangerous to draw conclusions from simple exercises, but maybe a small amount of upfront design is no bad thing. In reality I find it almost impossible not to think ahead when doing real work. I suppose the key practices are to delay over-commiting to a design until it is tried and proven; even then be prepared to change the design in the face of changing requirements, complexity, and knowledge.