Ian Cooper

Making your code easier to understand context/specification style unit tests

2009-06-29T04:08:00Z

When we started our current project we did not use context/specification style testing, instead we used testcase-per-class with a four-phase test model (also known as arrange-act-assert). Although we followed story-test driven development (STDD) we were not explicitly Behavior-Driven Development BDD when we set out. Over time I began to see the path between STDD and BDD we shifted toward a BDD approach.

That is really background for what comes next. As part of this shift we started writing more context/specification style tests. We did not re-write our existing testcase-per-class fixtures (then and still now I would see the possibility of using multiple test organisational patterns within a project; some of our tests still seem better with testcase-per-class). Recently we have had new developers join the team. One interesting, if anecdotal, observation has been that those developers find it easier to use tests as a source of documentation for what the software is doing when they are in the context/specification style. This is a useful observation, because the rest of the team is able to supply much of the context for testcase-per-class fixtures by virtue of having worked on the codebase and so do not see the lack so easily.

To build a maintainable system you have to build one where the behavior can be understood. Tests offer this promise, but often we have found that tests failed us, because the tests were no easier to comprehend than the code under test. Context/specification style tests seem to be better on this account. Of course there is no silver bullet in software. You still have to put the effort into making your context/specification tests readable, but the form seems helpful toward achieving that goal.

I'll try to post more on my experiences with BDD style approaches as they come out. I would also recommend that anyone interested in the topic look at the RSpec book from the Pragmatic Programmers which offers a great overview of the topic.

Should you learn frameworks or principles

2009-06-11T02:12:00Z

Normal 0 false false false EN-GB X-NONE X-NONE MicrosoftInternetExplorer4

There was a comment on the On Learning Boo post along the lines of : I only focus on learning frameworks, because they increase my marketability, learning new languages, ideas like DSLs just takes time away from that effort. It is a fairly common attitude. I have spoken to people who have told me that their focus is on learning the Microsoft .NET toolset, commenting that they feel that is enough of a challenge and one that translates best into career opportunities. I have seen recruiters and companies assessed with statements like 2 years of ASP.NET MVC as some means to indicate the competence of a developer to join a team.

At the same time for many developers the number of new frameworks tumbling out of Redmond makes it seems like a struggle to keep up. Those who feel that they must keep up, naturally feel overwhelmed. Restricting their focus to just what comes out of Redmond seems like a good strategy to manage the problem. Unfortunately, focusing on learning vendor frameworks is a trap. There will always be another new framework to learn to do what you were doing yesterday. Look at the churn in data access frameworks in the Microsoft space. Knowledge gained is quickly outdated. You end up on a treadmill, learning one vendor framework after another. You fall into the trap of appraising your next job solely on the criteria of what frameworks your prospective employer is using, just so that you can gain some experience using that new framework and keep your C.V. up to date.

Assessing developers by their knowledge of them, especially through certifications is an equally bad trap for employers to fall into. At best it is deceptive about what skills developers actually need. At worst it is a prison because the investment of knowledge in a particular technology becomes a ball-and-chain that makes individuals and corporations resistant to change. Having hired all those skilled Webforms developers and learnt all those vendor control kits, how could you rationally adopt ASP.NET MVC for your next project? After all you don't have any experience with it. Should you now dismiss your entire team and hire experienced ASP.NET developers? Or if you do change, what good did it do you to recruit people based on their understanding of the ASP.NET page lifecycle. Would it not have been better to hire people who had the skills to learn new frameworks?

When I was younger, I used to focus on learning the latest toolkit because I saw that as the best way to improve my marketability. I spent ages poring over the internals of MFC, ATL etc. I could talk about the details of the STL, Boost, Loki with the best of them. I wanted to be an expert on those libraries. I looked for new jobs when old ones did not offer me the opportunity to use the latest and greatest frameworks. Did it make me better developer? Maybe, but not in the way I expected. What I gained from poring over those frameworks eventually was an appreciation of the common underlying patterns. I might have learned something from understanding how the internals were implemented too, but it was pattern recognition of ideas like iterators, factories, template methods that gave me the most benefit. The next time I tried to learn a library, seeing how it solved problems I understood, seeing how it use patterns and principles I recognized, meant that I was able to being working with the framework faster. But I did this hard way, not by recognizing patterns I was aware of and seeing where they were implemented, but by discovering them seeing them repeated.

The reason so many of us get excited by books like Fowler's Patterns of Enterprise Application Architecture, his work on GUI Architectures of DSLs (and the work of others) is that they capture those patterns and principles. A solid knowledge of the principles relating models, views, and controllers would enable you to learn a range of web frameworks ore quickly because you look to see how they solve problems.

Learning new skills such as how to write a DSL in Boo will give you the breadth of aproaches that enable you to deliver better architected applications. The burden of maintenance is greater than the burden of writing, so a better architected application is always a good investment for a company. Far more than squeezing some obscure feature out of your latest framework is.

If anything the industry has moved on from those nuts and bots frameworks, and the abstractions have gotten better. Less and less do you need to understand the how and more and more the why? Knowledge of the patterns and principles provide continuing value to you as frameworks change. It also helps you understand how to use the frameworks, how to judge their quality against some kind of best practice yardstick and how to manipulate them when they fall short of best practice

As someone who interviews people I look more for understanding of the principles than the minutiae. The problem is that there will always be a new 'better' framework, a new popular paradigm. There is always the possibility that a new language comes along that we want to use instead for a given project. People who understand the principles can adapt. People who focus on the detail are intransigent to change, because they have too much invested in the framework that they have become an expert in.

Now before someone suggests otherwise I am not implying that people do not need to know how to use their tools to get the best out of them. Of course they do. But you will find a more efficient path to assessing and learning new frameworks through understanding the principles behind them than through learning each one in isolation.

Introduction to NHibernate, pt. 7

2009-06-04T03:56:00Z

In earlier parts of this series we looked at mapping via XML mapping files. I wanted to look at some alternatives to the angle bracket tax. First up is the Castle project's Active Record. Next time we will look at Fluent NHibernate.

Active Record Support for Attribute Based Mapping

While mapping via an xml file allows access to the full range of options that NHibernate gives us, it can be slow, because it forces us to context switch between C# and XML. Both NHibernate and Castle have attribute mapping options. NNHibernate.Mapping.Attributes is an add-in for NHibernate contributed by Pierre Henri Kuaté. Active Record is part of the Castle project, originally intended to support the Active Record pattern favored by Ruby On Rails.

We'll just discuss how to use Active Record's Attribute Support here. Essentially ActiveRecord contains attributes that are the equivalent of elements from the mapping file. For example to map the Customer class we mark it up as follows.

Adding the required references

We need to reference a number of assemblies to get ActiveRecord support:
Castle.ActiveRecord.dll
Castle.Core.dll
Castle.Components.Validator.dll
Castle.DynamicProxy.dll
NHibernate.dll

We also need to change our configuration file to configure ActiveRecord instead of NHibernate (ActiveRecord configures NHibernate from this information). We an configure either by a stand-alone xml file or through the app.config. For simplicity we configure through the app.config file here.

We need to add a config section handler for the active record section of our configuration file:

    <configSections>
        <section name="activerecord" type="Castle.ActiveRecord.Framework.Config.ActiveRecordSectionHandler, Castle.ActiveRecord" />
    </configSections>

The configuration mainly tells NHibernate how to access the Db. There are two key attributes of the <activerecord> element. We need to set the IsWeb attribute to true if we are an asp.net web application. We need to set the IsDebug attribute to true, if we want to see the generated mapping files (see below).

Note that when working with NHibernate 2.0+ the sample code given on the Castle site for Active Record uses incorrect key values that are prefixed with NHibernate. You need to change these to omit the "hibernate." from the name. If you forget to do this you will get messages about invalid key from log4net. This is because the hibernate.* keys are no longer in the schema.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<configSections>
    <section name="activerecord" type="Castle.ActiveRecord.Framework.Config.ActiveRecordSectionHandler, Castle.ActiveRecord" />
    <section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" />
</configSections>

<activerecord isWeb="false" isDebug="true">
    <config>
      <add
          key="connection.driver_class"
          value="NHibernate.Driver.SqlClientDriver" />
      <add
          key="dialect"
          value="NHibernate.Dialect.MsSql2000Dialect" />
      <add
          key="connection.provider"
          value="NHibernate.Connection.DriverConnectionProvider" />
      <add
          key="connection.connection_string"
          value="Data Source=.;Initial Catalog=nhibernate;Integrated Security=SSPI" />
    </config>
</activerecord>

<log4net>
    <appender name="ConsoleAppender" type="log4net.Appender.ConsoleAppender, log4net">
      <layout type="log4net.Layout.PatternLayout, log4net">
        <param name="ConversionPattern" value="%m" />
      </layout>
    </appender>
    <root>
      <priority value="DEBUG" />
      <appender-ref ref="ConsoleAppender" />
    </root>
</log4net>

</configuration>

Using attributes to peform our mapping

We mark the entity with an [ActiveRecord] attribute to indicate that we want NHibernate to persist it. We can add the table name if it does not match the entity name [ActiveRecord("MyTableName")]. We can indicate that we want the entity to be loaded, by adding the Lazy attribute as in [ActiveRecord(Lazy=true)].

We can declare that our class inherits from ActiveRecordBase if we want Active Record pattern semantics, i.e. the entity knows how to retrieve and persist itself. We want true seperation of concerns, so we do not intend to mix CRUD mechanics with our entity. For this reason we do not derive our class from ActiveRecordBase.

We mark up the identity of our entity using the [PrimaryKey] attribute. The default primary key type is native, so we do not need to mark this up, but if we have a different strategy then we have to explicitly indicate that. For example to use a GUID we would use: PrimaryKey(PrimaryKeyType.UuidHex, Params="format=D,seperator=-")]

We can mark up a property using the [Property] attribute. In addition, we can use [Field] if we want to map a private member of the class. If we need to map to a column with a different name to the property then we can pass it as a parameter to the attribute [Property("MyColumnName")]. If we have a large object then we can set the column type - see the the Active Record documentation.

We use a [HasMany] attribute to represent a one-to-many relationship, attributing the collection on the parent class i.e. [HasMany(typeof(Post), Table="Posts", ColumnKey="blogid")]. We use the RelationType enumerated value to specify the type of the relationship i.e. RelationshipType.Set. We also set the Inverse parameter as part of the HasMany attribute if this is a bi-directional relationship to avoid generating the insert and update statement, and creating an insert only. We can indicate if this relationship should be lazy-loaded using the Lazy parameter on the HasMany attribute. As with XML mapping we can also set the action NHibernate should take when we update or delete the parent using the Cascade option. In addition, we can set the index if we use one of the ordered types for our relationship or the sort order.
We use a [BelongsTo] attribute on the reverse side of the relationship to indicate a Many-To-One relationship. We need to pass the name of the foreign key column as a parameter to the attribute. Again there are options that reflect those available from the xml mapping file.

ActiveRecord also provides support for more advanced scenarios that are outside the scope of this article (it is meant to be an introduction and most of this is documented elsewhere):

HasAndBelongsToMany
OneToOne
Any and HasManyToAny

ActiveRecord also supports inheritance, supporting both the table Table-per-class hierarchy and Table-per-subclass strategies.

Mapping the Table-per-class hierachy strategy is straightforward, just set the parameters on the superclass ActiveRecord attribute to indicate the discriminator column to use i.e. [ActiveRecord("companies", DiscriminatorColumn="type", DiscriminatorType="String", DiscriminatorValue="company")] and then indicate the value for each of the sub-classes i.e. [ActiveRecord(DiscriminatorValue="firm")].
Mapping the Table-per-subclass strategy requires us to use the JoinedBase attribute on the superclass ActiveRecord attribute i.e. [ActiveRecord("entity"), JoinedBase] and then use the [JoinedKey] attribute on the shared key value of the sub-classes.

ActiveRecord also provides support for fine grained object models. We declare the [Nested] attribute on the property declaration in the containing entity, and then only mark up the component class with [Property] attributes i.e. not with [ActiveRecord] or [PrimaryKey] attributes.

Configuring Active Record

Before using ActiveRecord we must invoke the method Initialize on ActiveRecordStarter to configure NHibernate for us.There are a range of options to use when configuring, depending on where your configuration information is found. Because we added our configuration to the app.config file we can use the ActiveRecordSectionHandler to retrieve our configuration information.
ActiveRecordStarter also provides the functionality to generate our schema from our code.

            log4net.Config.XmlConfigurator.Configure();
            IConfigurationSource config = ActiveRecordSectionHandler.Instance;
            ActiveRecordStarter.Initialize(typeof(Company).Assembly, config);
            ActiveRecordStarter.CreateSchema();

Switching from attributes to mapping files

Active Record generates XML mapping files at run-time from your attributes, so this is using the same mechanism as the XML configuration, the complexity is just hidden from you. If you want to see the mapping then you can set the Debug value to true on the active record configuration (see above). This will tell NHibernate to keep the files around when your application ends, instead of deleting them.
This allows you to pursue a strategy of beginning development by using attributes, and then switching to .hbm.xml files later to fully utilize all options and keep your domain model clean of mapping information.

Active Record support for Session Management

Active Record removes the need to initialize a session factory explicitly, instead we use the ActiveRecordStarter.

IConfigurationSource config = ActiveRecordSectionHandler.Instance;
ActiveRecordStarter.Initialize(typeof(Company).Assembly, config);

For a web based application best practice is that we initialize within the Application_Start method of the global HttpApplication object.

Active Record operations try to get a session from the current thread, but create one if it is not extant, perform the operation and then release the session. So by default Active Record is session per operation. Active Record also gives us the ability to use a SessionScope to keep the session alive for the scope of our business transaction. Best practice is always to use a SessionScope.

            using (new SessionScope())
           {
                const string COMPANY_NAME = "CompanyOfWolves";
                InsertNewCompany(COMPANY_NAME);
                int companyId = FindInsertedCompany(COMPANY_NAME);
            }

For a web application the usual pattern is to create a SessionScope with request affinity

Active Record and Repositories

The problem with the Active Record pattern, where the entity exposes CRUD methods is that it does not enforce a clean separation of concerns. (We have not shown this but to get Active Record working this way we need our entities to derive from ActiveRecordBase). Knowledge about persistence is coupled with knowledge about domain responsibilities. This increases complexity and thus makes maintenance harder. So good design strives for persistence ignorance within its domain model. The repository lives within the domain model and represents a collection of entities from an aggregate root.

We call the repository from our domain level service to persist the object graph.

Support for Repository within Active Record

Active Record provides ActiveRecordMediator to allow you to use ActiveRecord to implement a repository.

   public class CompanyRepository
    {
        protected ActiveRecordMediator<Company> mediator;

        public void Add(Company item)
        {
            ActiveRecordMediator<Company>.Save(item);
        }
        public virtual this[ int id]
        {

get { return ActiveRecordMediator<Company>.FindByPrimaryKey(id); }
        }
        public Company[] Find(IActiveRecordQuery query)
        {
            return (Company[])ActiveRecordMediator<Company>.ExecuteQuery(query);
        }

        public Company[] Items()
        {
            return ActiveRecordMediator<Company>.FindAll();
        }

        public virtual int Count()
        {
            return ActiveRecordMediator<Company>.Count();
        }

    }

A quick example of using this repository (domain services etc. elided to remove complexity) would be:

     public static void Main(string[] args)
        {
            log4net.Config.XmlConfigurator.Configure();

            IConfigurationSource config = ActiveRecordSectionHandler.Instance;

            ActiveRecordStarter.Initialize(typeof(Company).Assembly, config);

            ActiveRecordStarter.CreateSchema();

            //Comment out the session scope to see lazy load lack of scope issues
            using (new SessionScope())
            {
                const string COMPANY_NAME = "CompanyOfWolves";
                InsertNewCompany(COMPANY_NAME);
                int companyId = FindInsertedCompany(COMPANY_NAME);
            }
        }

        private static int FindInsertedCompany(string companyName)
        {
            IActiveRecordQuery query = new SimpleQuery<Company>("from Company org where Name = ?", companyName);

            CompanyRepository companyRepository = new CompanyRepository();
            Company[] companies = companyRepository.Find(query);
            Company company = companies[0];
            Console.Out.WriteLine(company.Name);

            foreach (Customer customer in company.Customers)
            {
                Console.Out.WriteLine();
                Console.Out.Write("First Name: ");
                Console.Out.WriteLine(customer.Name.FirstName);
                Console.Out.Write("Surname: ");
                Console.Out.WriteLine(customer.Name.Surname);
            }
            return company.Id;
        }

        private static void InsertNewCompany(string companyName)
        {
            Company company = new Company();
            company.Name = companyName;

            Customer customer = new Customer();
            customer.Name.FirstName = "Neil";
            customer.Name.Surname = "Jordan";
            customer.DateOfBirth = new DateTime(1950, 2, 25);
            customer.Company = company;

            company.Customers.Add(customer);

            CompanyRepository companyRepository = new CompanyRepository();
            companyRepository.Add(company);

        }

AltNetConf UK London August 2009

2009-05-15T07:02:00Z

It feels as though sufficient water has passed under-the-bridge for us to have another altnetconf in London. We tend to organize them when the 'mood' seems right in the community. That usually means that we think folks have something to discuss. This time we are planning on the weekend of 1 August (31 JUL to 2 AUG). Registration should open on 12 May. Don't be alarmed if you see an old version of the site before then.

Numbers are still limited. The wider economy means that we are unlikely to get the sponsorship for a bigger venue this year. We'll keep trying though.

That said Alan Dean, Ben Hall, and myself have been plotting in secret, and roped in Sebastian Lambla and Michelle Flynne to help so that we can hold a bigger event in terms of the amount we do. So this time the plan is:

31 JUL Evening: Alt.Net Beers: Yes we are integrating Seb's alt.net event to warm you up with a chance to relax with like-minded individuals

1 AUG Day: Open Space Coding: Alan Dean's Open Space Coding Day event joins our weekend. the emphasis is on writing code over jawing.

2 AUG Day: AltNetConf: Open Space discussion about the topics that have grabbed you today. Be prepare to be surprised.

UPDATE: We had a request from attendees at Progressive .NET to delay registration, as they are a key attendance group. I'll update with the new time, likely to be Thursday lunchtime or evening.

UPDATE: We have now opened registration: http://www.altnetuk.com/registration.en.html

I'm looking forward to this one. It feels as though it has been long enough that we ought to have some things to talk about, not just re-hashing the old saws.

Finding out about London .NET events

2009-05-06T08:47:00Z

We have a rich .NET development scene in London and the organizers of a number of communities and events are going to try and make sure everyone knows how to get the best out of the community.

The first question for most people would be how to find out what is happening. For now the key site for you to bookmark is the UK .NET event site. The London communities are going to make sure that we all advertise our events their so that you can go to one place and see what is coming up.

As some quick examples of what is happening there I wanted to show you two events that you can find there which I am involved in. One is the Progressive .NET tutorials, which you can find on the calendar here. For those of you who can't fly out to events like Alt.NET Seattle it is a great opportunity to catch people like Ayende, Hammet, Bellware (and me).

On the 12th you can catch up with a lot of the same people down the pub as Seb has cunningly arranged the next Alt.NET beers to coincide with so many people being in town.

On Learning Boo

2009-04-14T03:18:00Z

Learning Boo

As part of my commitment to The Pragmatic Programmer's exhortation to learn a new language every year, I decided to tackle Boo. My interest has been piqued by the work Oren is doing in DSLs with Boo. Learning Boo seemed to be an important first step to getting to grips with that.

The first step was to get an environment in which I could write and compile Boo programs. Now this is possible using a decent text editor like Vim, and command line tools like booc and booish, but it is also possible to use an IDE for this. I downloaded SharpDevelop which has support for authoring, building and debugging Boo projects.

To give myself a starting point I have decided to work through the Boo Primer as a way of getting to know the language

One aspect that jumps out is why Boo is called 'wrist-friendly'. There is a lot of effort expended on giving you less to type. Although it is a statically typed language, Boo does away with the need to declare types before use. Instead Boo infers the type. C# programmers will find this similar to te use of var, without the need for the var keyword.

greeting = "Hello World" //This declares a string
houseNumber = 42 //This declares an integer

I'm always typing code of the form:

var myString = string.Format("Hello {0}", name);

in C#. Boo makes this a lot easier with string interning. I get to skip the string format statement, along with the seperation of placeholder and variable for

myString = "Hello ${name}"

The use of whitespace (Boo has a Python inspired syntax) to indicate a block is one of the early aspects of the language that strikes me. It makes for great natural language syntax, because it requires no block markers, but coming from a curly brace language "{}" like C# it takes a little for the fingers to get used to. I also seem to keep missing the colon off the end of the conditional

i = 5
if i > 0:
	print "i is greater than 0"
	if (i < 10):
		print "i is less than 10"
		if (i==5):
		      print "i equals 5"

One issue that hit me when working through the Boo Primer was that SharpDevelop disliked me trying to declare a list as follows:

L = List(range(5))

which gave me the error

ERROR: Generic types without all generic parameters defined cannot be instantiated.

Some digging on the Boo Programming Language mailing list established that Boo now has generics and it looks like the Boo interpreter in SharpDevelop uses that type over the non-generic type. Switching to use the generic collection instead, removed the error messages

L = List[of int](range(5))

The built in list initializer syntax seems to work in SharpDevelop though:

barfoo = ['abcdefghijkl']

I like the provision of initializer syntax for arrys, lists, and hashes within the language which provides for concise syntax

Overall I have spent an enjoyable half-a-day familiarizing myself with Boo's syntax so far. One immediate advantage to learning Boo over say learning Ruby is that you are dealing with .NET libraries. So when you see Console.ReadKey(true) in a line of Boo code your existing knowledge tells you what it is doing. You are able to leverage existing framework skills and apply them to a new language. This speeds up the learning process, because having learnt the new syntax you can to put it to use fare more quickly.

Next time I'll play with Boo's methods and classes. Looking forward to it.

Seizing the BDD Nettle

2009-03-31T07:06:00Z

Learning BDD

I have been trying for some time now to understand what the Behavior Driven Development (BDD) exponents are talking about. I'm sure that Scott and Colin Jack are sick of me asking questions on BDD.

This is pretty much a journal of my understanding. It might help others on a similar journey, hence the reason for blogging it. I know a number of people have been asking me about BDD recently at community events, so this is an attempt to share where I am in understanding so far. Be aware that there may well be misunderstandings here. I'm not claiming any kind of authority for BDD. Hopefully more experienced practitioners will help me to correct any mistakes. Please use the comments. As my understanding improves I'll keep you posted.

For now be aware this is really a 'notes to self' blog.

The approach of this post is mostly historical. That is mostly because my current understanding of BDD is that it is an opinionated packaging of ideas from STDD, ATDD, and TDD. So I find it helpful to understand the ideas it is built on and where current skills form a part of the BDD mix.

A key resource for me in understanding BDD is Scott Bellware's Code magazine article on the topic. The opinions here are my own though.

Behavior Driven Development in a historical context

On the current project we are practicing Industrial XP's StoryTest-Driven Development. That article dates from 2004 but the practice and tools such as FIT have been around longer. For example Customer Test Driven Development, a prior name, was a paradigm as far back as 2002. STDD supplements the unit tests of TDD with acceptance tests (usually delivered in FIT or Fitnesse). The key principle in STDD is that you write new code only if an automated storytest has failed.

It might seem obvious now, but the goal of agile engineering practices is to move the process of acceptance up the chain. When acceptance occurs at the end, it is expensive to fix mistakes. Developers have to re-acquire the depth of understanding they had when they first developed the feature. It leads to 'never-ending' projects as acceptance drags on and on with the customer submitting more and more changes. Pushing acceptance up to the point that the code is written shortens the feedback loop making less expensive to fix issues. Pushing it ahead of writing the code prevents those defects occurring in the first place, the ideal.

STDD helps us focus on creating the acceptance criteria first, so that we prevent defects instead of fixing them after they occur.

In addition, STDD helps focus on the communication between Customer and Developer, clarifying the requirement. The article quoted above makes reference to Domain Driven Design in its comment that it is important to share the customer's language in these tests, the DDD idea of ubiquitous language.

One aspect of STDD to note is that we have a separation between the customer tests and the unit tests. Customer Tests remain the same regardless of how we choose to implement. Unit tests cover the implementation details.

Implicit in the name - story test-driven development is that we are working with user stories and the acceptance criteria on them. Interestingly this is often less explicit in descriptions of the technique, presumably because XP practitioners assumed everyone was working with stories and acceptance criteria.

We use a mixture of Fitnesse and Selenium for acceptance testing but equivalent tools exist. Acceptance testing tools remain woefully high friction and seem a clear area where improvements could be made.

Of note is whether you use an Outside-In or Inside-Out approach. Most descriptions of STDD are Inside-Out. Although the developer has the acceptance tests as a target they then build unit-tested code from the bottom up to implement the requirements. Often the developers use a white-board or CRC card session to design the implementation. Then, at the end, they hook up the acceptance test to see everything pass (or fix anything that is not as expected). This is generally how we work on my current project. BDD descriptions often focus on an Outside-In approach. Outside-In relies on greater use of Test Doubles to replace depended upon components (DOC) that are not yet implemented. Adherents see a benefit in the design that emerges from being forced to make the DOC abstract.

Acceptance Test Driven Development

To me Acceptance Test Driven Development (ATDD) is just another name for Story Test-Driven development. Both ATDD and STDD emphasize the idea of the executable specification. We make it possible to demonstrate that we meet the specification and can keep meeting it. I guess someone may put me straight if the two differ in philosophy. I heartily recommend Gojko Adzic to learn more about ATDD, particularly the interaction between customer and developer that occurs as part of that process.

Unit tests are not enough

We moved from a focus on unit tests and integration tests today, to add test-first acceptance testing to our strategy. This can be hard, because you are used to loading to testing at the back of the iteration (or even in the next iteration). Moving acceptance testing to the beginning of the story requires you to have a conversation about how you will accept the story, with customer and test engineers if you have them, before you start the story.

In addition, you need to keep stories small so that you have acceptance throughout the iteration. It is no good defining scenarios up front if you end up confirming them at the end of the iteration. There is the pragmatic issue of overloading your test team, but also the problem of late feedback. That can be a hard discipline and we often end up with too much acceptance at the back end of the iteration from having insufficiently granular stories. We're still working on getting better at getting our acceptance across the iteration, and it remains a real challenge. It's one with an enormous payoff though. It is also worth noting that our failures are not failure of the goal, but a failure to excel well enough at breaking up epic stories etc.

The value add in the approach is preventing defects rather than detecting them. It is also how stories were always supposed to be used - as a promise for a conversation. This seems to be much the same insight that pushed lean manufacturers to move QA into the line to prevent defects occurring instead of simply having them point them out once they had occurred. Testing 'at the end of the line' is an anti-pattern that can only detect defects not prevent them.

Behavior Driven Development

Dan North coined the term Behavior Driven Development (BDD) to replace TDD. Dan felt that the emphasis on testing in the names used to that point was a distraction from the idea of confirming the behavior of the system or executable specifications. Dan's history of BDD suggests that it began as an attempt to use Behavior Specification over unit testing (see below). At first this was simply a question of naming test fixtures to indicate that they were assessing behavior and naming tests to indicate the behavior under test. This lead to the development of a tool, JBehave, as a clearer alternative to the unit testing tools that were prevalent. Dan then realized that the emphasis on behavior meant the technique could also encompass the process of acceptance criteria for stories as well. For me one transition in BDD thinking that seems distinct from STDD and TDD is that it removes the idea of these being separate activities, pitching more an idea of scenarios and specifications instead of different granularity of tests.

Acceptance Testing again

STDD, ATDD, and BDD all emphasize the same thing: unit testing is not enough, even if done test first. The problem is that while unit testing tells us that we have built the software right, it does not tell us if we have built the right software. In an analogy you may be great at cutting down trees, but if you chop down the wrong forest, you've bought yourself nothing but trouble.

The classic model for development under BDD, seems similar to that for STDD, but we move from acceptance tests and unit tests to scenarios and specifications. This terminology change helps us think about the work as automating executable requirements instead of testing. That re-focuses us on these as design activities. They also improve the maintainability of the artefacts produced, because the strategy is inherently contextual. Note that when I say developer here, you might have a specialized software developer in test (SDT). When I say customer it might be a customer proxy such as a Business Analyst (BA)

Developer works with customer to find user stories of form: As a <role>I want to <business activity> so that I <business value>
Developer works with customer to identity the acceptance criteria for that story
Developer writes a scenario that exercises part of the acceptance criteria of the scenario (in a Given-When-Then style). Tools like Fitnesse and Cucumber often present these customer facing tests. However, tools are not the issue here. Some folks may use an xUnit framework even at this point.
Developer implements fixtures to create a failing scenario
The developer may do some design with colleagues on a whiteboard, CRC cards etc.
Developer writes a failing specification for a part of the implementation that will satisfy the story. This was traditionally the unit test, but BDD shifts the perspective to a specification to ensure we still think about execuable specifications over tests (see below for more)
Developer writes the code to get the specification to pass
Developer keeps writing new specifications, until the scenario passes
Developer moves on to the next scenario for the acceptance criteria for the story

It's important not to emphasize tools here. It is not a question of using Fitnesse, Cucumber, or Selenium for your scenario and a particular xUnit for your specifications but a question of thinking about how we accept software. You might, for example, use SpecUnit throughout here; or you might use Fitnesse and NUnit with a home rolled specification framework.

Behavior Specification

For some time we have been using the Four Phase Test approach. We were often explicit about the steps within a test method having an in-line setup, exercise, verify and teardown section within the test. Some people were writing this as Arrange, Act, Assert (AAA) when working in-line and we switched to using those monikers as it seemed to be more prevalent. The advantage of using a strict phase model is that it became easier to read tests - you knew how any test would be structured, where to find the pre-conditions and post-conditions and what was being exercised.The model also forced people to think about how they were highlighting the conditions important to the test, leading us to use ideas like Test Data Builders.

BDD uses the phrase Given-When-Then to refer to the phases of the test model. The naming was a deliberate choice. The idea was to focus on a specification of what the Sysem under test (SUT) should do instead of focusing on verifying parts. Shifting the names took us out of the world of tests and into the world of executable specifications. We stop thinking about setup and start thinking around the context in which the business activity is occuring. We stop thinking about calling our API and start thinking about the operation being performed. We stop thinking about testing and instead focus on outcomes.

RSpec changed the convention here to focus on Examples or Specifications. Dave Astels speaks about Behavior Specification as an alternative mindset to testing. That approach was picked up by many others including Scott Bellware in SpecUnit.

By focusing on a specification, Behavior Specification psychologically shifts us from thinking about testing into writing an executable specification for our code. With a user story approach the detail of the requirement is in the acceptance criteria so this shift to see testing as specification is just the natural outcome of thinking of requirement specifications as the driver for testing, providing the notion of expected behavior.

Objects can be described as having a push-button API. Our calculator class has Multiply, Add etc. The danger with TDD is that it can lead to testing button rather than operations. You write a test to enter '2' and see it displayed on the screen. You write a test to press the Add button. But what we really want to test is that when In I add 2+2 I get 4. TDD can produce tests that don't cover the whole specification, but fragmentary parts of it. This makes them hard to 'read' and do not form effective executable documentation for our system. We want to be able to read the tests and know what the code is supposed to be achieving, not that the bits function. People who have delivered large systems using a classic approach to TDD have found that the tests are not expressive enough to act as clear documentation of the system. Specifications are much better in this regard. The skills are the same but the focus of the approach shifts from testing to specifying. This 'eureka' moment of understanding the shift between unit tests and specifications seems to be one of those difficult to explain, but easy to appreciate areas of life.

There are additional benefits. The shift to specifications for example seems to lower the issue of property heavy APIs on a class. With unit tests, the calling code can end up containing the behavior - the workflow of calls required to complete an operation. A specification surrenders control of that back to the SUT. So a specification approach should drive the design of a better API because we focus on what we want to achieve not how we achieve it.

It's turtles all the way down

It's important to understand that this approach -writing a specification of how the system should behave when something happens within a context (Given-When-Then) applies throughout the stack. So the traditional dichotomy of acceptance tests and unit tests fades to be replaced by tests at different levels of granularity, potentially using different tools as appropriate.

That is enough for now

There is more to say, but this has been a long enough post for people to read, so I'll defer anything else to some subsequent posts on the topic. Those looking for examples of how might want to read Scott's article for now. I'll try to post some examples later. However one key for me was to share my current understanding is that simply using behavior specification xUnit frameworks is not 'doing BDD'. BDD is a whole lifecycle approach to verifying you have met user requirements. In that context I suspect that focusing on individual frameworks may distract from, rather than enhance, the message.

Introduction to NHibernate, pt. 6

2009-03-26T08:55:00Z

Last time we looked at mapping value types and user defined types. This time I want to look at sessions. Understanding sessions is one of the challenges for any developers approaching ORMs for the first time, because they can represent a new way of thinking about interaction with the Db.

Normal 0 false false false EN-GB X-NONE X-NONE MicrosoftInternetExplorer4

Working with Sessions

We need to use a session when we work with NHibernate. We will talk later about managing entity lifetime, but the short version is that you should avoid accessing an entity outside of the context of the session that loaded it.

We obtain sessions from the session factory. The session factory is an expensive resource, you want to create it once at application startup. The factory gives you instances of sessions, which are cheap and you should create and destroy as your business transactions require (see transient and persistent entities below).

Entity Lifetime Management

It is important to understand the lifetime issues around entities when working with an ORM. Clarity here helps prevent many of the issues people have when working within an ORM.

Identity Map

The identity map is a cache of all of the entities loaded from the Db during the session. We need an identity map because we want to ensure that if we have made changes to an entity within the session i.e. updated some of its data, new queries against the Db that returns a set of entities keep our changes. As a corollary to this when working with an identity map, we always get the same instance of an entity within a session, and they can be compared by reference. Note that the identity map also functions as a first-level cache, because it has our entities loaded. However, we will only go to the first level cache in preference to querying the Db when using Get or Load to retrieve our entities. This is because only when we issue a query, through HQL for example, we do not know what entities will be returned, so it is only after the query is executed that we can look into the cache to se if we have that entity already, and return the copy there.

Unit of Work

NHibernate stores the old and new values of entities within the identity map. The unit of work also stores new entities that have been added with Save and are waiting to be flushed to the Db. NHibernate flushes these changes to the Db both on demand and automatically. Automatic flushing happens when you perform certain operations. For example if you are about to query NHIbernate will flush to make sure that your query results will be consistent with the modified data. You can also explicitly flush a session either by calling Flush() on the session or by using a transaction. The principle here is that you want to optimize when updates occur, instead of them happening piecemeal.

So when does NHibernate Flush?

- When you explicitly call Flush.
- When you commit a transaction.
- Before some Find or Enumerable method calls
- When an object using native ID generation is saved, the entity will be inserted
- Whe you close a Session

We can set the session FlushMode to restrict those to Commit or Flush if we need to be explicit about when a flush occurs. One common reason for setting the FlushMode to Commit is the issue of what happens when an exception is thrown. It is common to have a using statement control your Session, so that it is closed when and flushed automatically. The problem becomes that if you throw an exception, the Dispose still runs as you exit the implicit try..finally block created by the using statement, flushing and pending writes. Given that an exception was thrown this might result in an incosistent or undesired state. Setting the session FlushMode to Commit and always using a transaction helps prevent this: the changes don't get persisted until you commit. The side-affect to watch for is the issue that until your changes are flushed, queries will not report on any pending changes.

Transient and Persistent Entities

We need to distinguish between transient and persistent entities. A persistent entity is one that the session knows about. The session knows about an entity that has been loaded through it, using get, load, or one of the query APIs. A transient entity is one that the session does not know about i.e. has been created with new in the application. A transient entity is made persistent by calling Save() on the session passing the new entity as a parameter, or by adding it to the graph of an existing persistent entity. In the latter case we will persist the new entity if we have set the cascade options in the mapping to pickup children.

We need to remember that an entity has its changes tracked by the unit of work held by the session which loads it. In addition, if we have lazy loaded associations on an entity, those will be loaded via a proxy that calls out to the original session. So we should not access an entity outside the scope of a session. The model in NHibernate is:

Open Session
- Begin a transaction on the session
  - Retrieve any required entities
  - Save any transient entities or add to graph
  - Make any updates to the graph required
- Commit the transaction
Close the session

If we have a detached entity, one that we loaded via a transaction that is no longer extant (remember we don't want any lazy loaded associations on it), because we have loaded it within a different context, then we can re-attach it to a session using Update(). Update tells the session that the entity it thinks is transient, because it is not in its identity map, is actually persistent. In that case NHibernate adds it to its list of persistent entities.

NHibernate also supports SaveOrUpdate() which is useful if are not sure if the entity is detached or transient. In this case it uses the unsaved-value attribute of the primary key mapping to determine whether or not we have a transient entity or a detached one.

A common early mistake is to assume that the Update method needs to be called to amend a persitent (i.e. existing object). In fact you do not need to explicilty ask for changes to persistent objects to be saved. NHibernate looks in the Unit of Work to figure out which objects are 'dirty' and flushes any changes to them.

Although there is support for detached entities, prefer to work within the context of a session where possible as it prevents issues with needing to fully materialize the object graph.

If we have a transient object which is in the reachable from the graph of a persistent object, then we do not need to explicitly save it. NHibernate will pick up the transient object and save it for us when it saves the persistent object provided that we have set the association between the persistent object and the transient one to cascade saves or updates. This works well with an aggregate strategy where your repository laods and saves aggregates (via the aggregate root) as you only ever need to save the root object to persist the graph.

CRUD

Insert, and Retrieve

Inserting a new object is straightforward. Create it, and make it persistent with Save. We use flush here to persist it instead of using a transaction:

Company company = new Company();

company.Name = companyName;

Customer customer = new Customer();

customer.FirstName = "Neil";

customer.Surname = "Jordan";

customer.DateOfBirth = new DateTime(1950, 2, 25);

customer.Company = company;

company.Customers.Add(customer);

using (ISession session = sessionFactory.OpenSession())

{

session.Save(company);

session.Flush();

}

Once we have saved our entity we can retrieve it. If we do not know the id of the entity then we need to use one of NHibernate's query languages, HQL or ICriteria to find it.

HQL is a SQL like query language that works against the domain model instead of the relational model. Queries have the form "from Customer as cust where cust.FirstName = :name". ":name" is a named parameter, you can also use "?", but then you have to refer to parameters by position when setting them, so by name is usually more readable.

The Find method on session has been deprecated, so use the CreateQuery on the Session to create an IQuery, set your parameters and retrieve matching results.

using (ISession session = sessionFactory.OpenSession())

{

IQuery query = session.CreateQuery("from Company org where Name = :name");

query.SetString("name", companyName);

IList<Company> companies = query.List<Company>();

if (companies.Count > 0)

{

Console.Out.WriteLine(companies[0].Name);

foreach (Customer customer in companies[0].Customers)

{

Console.Out.WriteLine();

Console.Out.Write("First Name: ");

Console.Out.WriteLine(customer.FirstName);

Console.Out.Write("Surname: ");

Console.Out.WriteLine(customer.Surname);

}

return companies[0].Id;

}

In addition NHibernate also provides the ICriteria API

If we know the Id we can use Get or Load. The primary difference is that Get returns null if the entity cannot be found, whereas Load throws an exception. However, also note that if the object exists as a proxy in the session's identity map then Load will return that proxy, Get will always retrieve the entity.

using (ISession session = sessionFactory.OpenSession())

{

Company company = session.Load<Company>(companyId);

Console.Out.WriteLine();

Console.Out.Write("Company Name: ");

Console.Out.WriteLine(company.Name);

}

Delete and Update

Updating an entity is straightforward, any entity that is in the identity map that we then update will have those changes persisted when NHibernate flushes to the Db.

string companyName = string.Empty;

using (ISession session = sessionFactory.OpenSession())

{

Company company = session.Load<Company>(companyId);

companyName = company.Name;

ITransaction trans = session.BeginTransaction();

Customer newCustomer = new Customer();

newCustomer.FirstName = "Angela";

newCustomer.Surname = "Carter";

newCustomer.DateOfBirth = new DateTime(1940, 5, 7);

newCustomer.Company = company;

trans.Commit();

}

Deleting an existing company is straightforward too, we simply call the Delete method of the Session to remove it.

using (ISession session = sessionFactory.OpenSession())

{

session.Delete("from Company org where Id = :id", companyId, NHibernate.NHibernateUtil.Int32);

session.Flush();

}

How long to keep the session around?

Sessions are lightweight resources and designed to be 'kept around' as long as you need them. For example, the session only opens and closes a Db Connection when it flushes changes in the unit of work to the Db. A session is also easy to create, so you should create them as you need them. By contrast the SessionFactory from which we get our sessions is a heavyweight object. It does all the work to generate code from the mappings, and generally you want to create this once, at application startup. The usual pattern is to create a session for each business transaction, for which you may be collating changes in a unit of work. On the web, it is common to use Http request affinity for a session, opening a session as the request comes in and closing it once you have returned the response.

Introduction to NHibernate, pt.5

2009-03-22T11:29:00Z

Last time around

Last time we looked at how we map inheritance in NHibernate. This time I want to look at value types.

Mapping Value types

NHibernate supports a 'fine-grained object model'. That is to say it allows us to map value types as well as entities.

All ORM tools let you map between a class and a table. This provides us with the support we need to map the entities in our domain model. Entities are distinguished by having a unique identifier throughout their lifetime; that is to say we compare entities by identity, not by value. As an example, the tax system needs to continue to find you, even if you change your name, so you will have some form of tax number that acts as your unique identifier. The mapping used is straightforward. Because each row in a Db table needs a unique identifier (the primary key) a row can be seen as equivalent to an instance of an entity.

It's obvious that all ORMs need to support mapping the primitive types (int, string, bool, etc) that you comprise your entity from. Again the principle is simple, each field or property on your entity maps to a column in the table.

Less well understood is that primitive types are just one class of types that we call value types - that is types that we compare by value. When we build our object model we may find a host classes in our domain that should be compared by value instead of by identity.

The canonical example here is money. When we record a monetary value we may want to know two things - the amount, and the currency. When we compare for equality between two monetary amounts we tend to compare that they have the same currency and amount. In an OO design we want to keep the two concepts, value and amount, together so we create a class called Money.

Within the Db we would tend to represent money and amount as two columns, within the entity, such as a purchase order line item, we were recording the cost of. If our ORM only supports mapping entities though we will find that the only way to represent money and have it mapped to two columns on the LineItem table is to explicitly represent the monetary amount as a amount field and a currency field within the LineItem. We cannot use Money, because the only way that our ORM knows to map a class is as an entity, so we would have the somewhat perverse scenario of having a foriegn key lookup to the Money table to find the cost.

What we want is to be able to map a value type to a number of columns on a table. (You don't have to map a value type this way, but it makes the most sense in most cases). NHibernate allows you to map user-defined value types or collections of value types. We won't show the latter here, as it’s not really an introductory topic, but we will talk about the former.

NHibernate uses the term component for a user-defined type that is mapped to columns in the row of another entity. We use the <component/> element to map the value type on the <class/>.

Consider, for example, that we might want to map the Customer's FirstName and SurName as a Name type. (We are using the same entities that we provided earlier in the series). We could alter the class definition as follows:

public class Name
{
public string FirstName {get;set;}
public string Surname {get;set;}
}

public class Customer
{
public Company Company { get; set; }
public DateTime DateOfBirth { get; set; }
public int Id { get; set; }
public Name Name { get; set; }
public int Version { get; set; }
}

Then we can map it as follows:

And that is all there is to it.

User Defined Mappings

NHibernate also has support for providing custom mapping for any type, allowing you to take control of how objects are persisted and materialized. In some cases you may want to use this to take more control of your mappings. To add a custom mapping you need to create a class that derives from IUserType (for single field types) or ICompositeUserType (for types with multiple fields). Custom mapping is too large in scope for this article to cover completely, butwe'll try to cover the basics.

Let us assume that we want to map our Name above using a composite user type instead of a component

We create a new type NameUserType and implement the ICompositeUserType interface. Essentially NHibernate calls our composite user type to materialize or persist instances of our value type. Those of you who have written ADO.Net persistence code for a data reader by hand will probably recognize how this works.

public class NameUserType : ICompositeUserType
{
     private static readonly SqlType[] sqlTypes = new SqlType[] {NHibernateUtil.String.SqlType, NHibernateUtil.String.SqlType};

     public object GetPropertyValue(object component, int property)
     {
         var name = (Name) component;
         if (property == 0)
             return name.Firstname;
         else
             return name.Lastname;
    }

    public void SetPropertyValue(object component, int property, object value)
    {
         //our value type is immutable, we create a new instance instead of modifying
         throw new InvalidOperationException("Name is immutable");
    }

    public bool Equals(object x, object y)
    {
         if (object.ReferenceEquals(x,y)) return true;
         if (x == null || y == null) return false;
         //our type should know how to compare itself
         return x.Equals(y);
    }

    public int GetHashCode(object x)
    {
        //our type should provide a hashcode
        return x.GetHashCode();
    }

    public object NullSafeGet(IDataReader dr, string[] names, ISessionImplementor session, object owner)
    {
        var firstName = NHibernateUtil.String.NullSafeGet(dr, names[0]);
        var lastName = NHibernateUtil.String.NullSafeGet(dr, names[1]);

        return new Name
        {
             Firstname = firstName,
             Lastname = lastName
        };
     }

    public void NullSafeSet(IDbCommand cmd, object value, int index, ISessionImplementor session)
    {
        if (value == null)
        {
            ((IDataParameter)cmd.Parameters[index]).Value = DBNull.Value;
            ((IDataParameter)cmd.Parameters[index+1]).Value = DBNull.Value;
        }
        else
        {
            var name = (Name)value;

            ((IDataParameter)cmd.Parameters[index]).Value = (object)name.Firstname ?? DBNull.Value;
            ((IDataParameter)cmd.Parameters[index + 1]).Value = (object)name.Lastname ?? DBNull.Value;
        }

    }

    public object DeepCopy(object value)
    {
        //As an immutable value type, just return the argument.
        //If we were an entity we would need to deep copy
        return value;
    }

    public object Disassemble(object value, ISessionImplementor session)
    {
        //write to 2nd level cache
        return value;
    }

    public object Assemble(object cached, ISessionImplementor session, object owner)
    {
        //read from 2nd level cache
        return cached;
    }

    public object Replace(object original, object target, ISessionImplementor session, object owner)
    {
        //we are immutable
        return original;
     }

     public string[] PropertyNames
     {
        //What are the names of our user types properties
        get { return new string[] {"Firstname, Lastname"};}
     }

     public IType[] PropertyTypes
     {
        //What are the types of our user types properties
        get { return new IType[] {NHibernateUtil.String, NHibernateUtil.String}; }
     }

     public Type ReturnedClass
     {
        get { return typeof (Name); }
     }

    public SqlType[] SqlTypes
    {
       get { return sqlTypes; }
    }

    public bool IsMutable
   {
      //we are immutable
      get { return false; }
   }
}

If we can map Name by both a component and a user type why would we ever want to use a user type? One answer is simply to save duplication in our mapping files. But a more complex answer is that you may want to map a family of types through an interface, that all share the same state, but have differing behaviour. You need to distinguish which concrete type NHibernate should use to materialize this instance from the store. You can write code within your user type to manage that.

The key takeaway is to recognize that NHibernate supports a rich domain model better ORMs, for example Linq To Sql, that do not have support for mapping value types.

Why people do not see how smart your idea is at first

2009-03-06T08:57:00Z

One of the 'features' of my current project is that the development team are seperated by the Atlantic from the analysts. So we have to learn overcome the resulting communication issues. One observation that we have from that experience is why other people do not always 'grok' your new great idea.

A scenario we experience commonly is that the developer team and the analysts begin discussing a problem in the shared working hours of the day. During our shared time we may move from steps A-H of solving a problem. But in the interim one team or the other may take a way the problem and keep working on it and take the problem from I-Z reaching a conclusion. When the team meets up again, the team that continued working on the problem presents their solution Z (usually with a drum roll) in full expectation that the other team will laud their clever solution.

But what usually happens is the other team start asking questions. Why would you do it that way? What was wrong with this solution? Often the presenting team are dissappointed and furstrated. Why don't you get my beautiful idea? Why don't you just accept what I am saying to you?

The problem is of course that one team is at H and the other is at Z. You can't just skip all the steps in between. The team presenting has to walk the team that need to catch up from I to Z so that the lagging team can understand the reasoning that led to their conclusion. As my math teacher used to say: show all your working.

As a community Alt.Net often experiences this problem. We leave the path everyone else is on at H and run all the way to Z. When we come back and tell everyone else that Z is now the way to go, there is questioning and disbelief, because we left the broader community at H. If we want to communicate effectively we have to summarize I to Z.

The Peristence Ignorance conversation at Alt.Net Seattle was a great example of this. You cannot just present Persistence Ignorance and expect folks to adopt it. You have to explain what steps (testability, seperation of concerns, single responsibility etc.) lead you to prefer persistence ignorance and how tools that do support it achieve that.

Of course we could put our head in the sands and just say it's up to the rest of the community to work through I to Z, but too often we do not document our footsteps well enough for others to follow in them.

Persistence Ignorance with LINQ To SQL

2009-03-03T13:51:00Z

I do not usually just re-point to older blogs, but some people including Don Smith were asking in the Persistence Ignorance session at Alt.NET Seattle about support for PI with LINQ To SQL.

I would maintain that LINQ To SQL supports a PI approach. I talked about it originally here but you might also want to read the relevant sections of my series on Architecting Applications with LINQ to SQL which cover mapping here and here.

The major lack is around support for a fine-grained object model i.e. you can't map a value type to one or more columns only entities to tables. However, I don't think that is a PI issue, but a modelling issue.

ALT.NET Seattle 2009, some impressions

2009-03-02T19:52:00Z

Having just got back from Alt.Net Seattle 2009, I wanted to post a few reflections. Mostly this is just a dump of things that grabbed my attention - its not meant to be any kind of documentation of the convesations there. I would also like to thank all the organizers for their effort - I had a great time - and my fellow delegates for stimulating and challenging conversation.

DTOs, Messages, and the Presentation Layer

I hosted this session. Given parallels with a morning session, it evolved into a discussion of communication between the domain layer and the presentation layer. The question many of us had was whether the consensus was that the presentation layer could depend directly on the domain model, or should depend on a seperate model that acted as an intermediary to the domain layer. Broadly there was agreement that the advantage of a specific model was reducing the coupling between the presentation layer and the domain layer by keeping the presentation layer igorant to the structure of the objects in the domain. Udi Dahan pointed out that many of us were using the term DTO incorrectly to describe the composition or projection of data from the domain model into a shape that we needed for the view, pointing out that this was actually the Presentation Model. DTOs as a pattern represent on-the-wire serialization of data between to physical layers, not seperating between a 'behind-the-glass' view of the data and the domain model. That clarification helped the conversation to realize that the principle we needed to talk about more was command-query seperation (CQS). We query for the presentation model, composing or projecting as required, and we update the domain model through a command. I realized that my conversations on this one had used lazy mis-application of the DTO name, and the session should be a good kick-in-the-pants to use terminology more carefully here.

Can MS help with DDD Tooling

Udi challenged my thinking again in this session with the observation that in DDD the Aggregate Root is a role. The interesting part of this idea is that it allows us to treat aggregate roots (AR) polymorpically so that we provide separate interfaces for the use of the AR - the Interface Segregation Principle . Some things fall out nicely once we do this. The first is the simplicity within the service layer of interacting with the AR now that we have reduced its surface area. But we can also make other decisions based of the fact that we now understand the context we are using the AR in. As an example, orderRepository<IEnterNewOrder>.Get(id) now carries enough information to allow the repository to decide which portions of the object graph need eager loading and which need lazy loading. Another is that if we want to use behavior based testing instead of state based testing on our service layer (because it holds no state) then we can easily provide a test double for the interface to the aggregate.

Is Persistence Ignorance Necessary

Ward Bell did a great job in facilitating the discussion, clearly setting out his understanding of PI and his concerns around it.There was a broad consensus that Persistence Ignorance (PI) within the domain model brought benefits to the developer (low friction,well-seperated concerns) but Ward's question was to whether this meant paying a high price within the infrastructure layers where that PI was implemented. I believe that those of us who favor PI were able to get agreement from those who are still doubtful that if it was easy to implement persistence with PI as without, then they would support PI, because they could see the benefits. Obviously the NHibernate fans felt that the cost of supporting PI was well worth the benefits. But, it's always seems easy when you know how. It's always worth the PI believers remembering that they had to make the effort to learn the paradigms that NHibernate uses to support PI (sessions, transient and persistent objects etc.) before they could reap its benefits. So the feeling that PI takes effort is understandable, because there is a learning curve the first time you use an ORM that supports PI.

But the conversation ended positively because many of the doubters seemed to be more open to deeper exporation of NHibernate in order to more clearly understand why those using NHibernate do not find the cost of supporting PI an issue. Overall a session that could have been very fractious ended up being very fruitful.

Why We Stopped Using the Auto-Mocking Container and What's Next

Aaron Jensen hosted this one. He shared his experiences of the issues with over-use of mocking within your tests. I was interested to see this one emerge because I have posted about it before, from my own experience,and in our discussions at altnetconf in the UK, but not really seen much acknowledgement of it from the other side of the pond.

It's timing is also ironic because although we prefer state based testing in our domain layer, I am starting to move toward preferring use of behavior based testing in the service layer precisely because services have no state to test, and I don't want to test the state of the Depended-Upon-Components (DoC) from my Service Layer. The conclusion from the fact that both absolutist approaches lead to issues would seem to be that an appropriate combination of behavior and state based testing is needed, depending on the characteristics of the System Under Test (SUT).

One issue with a state based approach is that it is harder to see how it works with a top-down or outside-in approach to building your components as opposed to an inside-out or bottom-up approach to development, because the top-down approach relies on stubbing out components. We tend to use CRC cards or whiteboard sessions to determine what to build. Fitnesse tests work well with this style too because we can define failing tests prior to providing an implementation. We then build bottom-up, assuming the risk of some re-work for un-needed objects or methods will be small. Aaaron was investigating a best of both world's solution that would allow him to combine the design benefits of a top-down approach with the amenability of state-based testing to change. It will be interesting to see how that develops.

With Services the focus is on behavior

2009-02-21T15:54:00Z

This post is really just tying together some ideas. A year ago I posted on my preference for classicist TDD. However, when it comes to services you are dealing only with behavior not state so using classicist approaches becomes trickier. One way out of this issue is to test the results of the service on the stateful objects (entities, repositories) that the service interacts with. Having experimented with that style the outcome is usually unsatisfactory because the service's tests frequently mirror the tests against the stateful objects themselves. That leads to un-needed code (or worse duplicated code) in the tests, and multiple tests failing when you get something wrong.

So I think this is one of those cases where it is clear that the way to test the System Under Test (SUT - the service you are testing in this case) is by its interaction with its depended upon components (DoC).

I also think that this approach helps prevent the obesity issues with Fat Controllers and Flabby Services because it discourages you from adding much additional behavior to your service beyond command and control logic, because it is then hard to test that outcomes of that logic.

So in the context of services I would vote for looking at 'mocking' as an approach.

For controllers, we have found auto-mocking containers to be a powerful way to get our code under test.

"Inappropriate Intimacy" points to the bleeding out of your domain logic

2009-02-19T09:24:00Z

A while ago I posted about Fat Controllers. Another area that can quickly get beyond you are any domain level services that you have. Often this is exactly what your controllers are calling. Services should have no state and do co-ordination and control. Your domain logic should not live in the service layer, it lives in the entities that your service co-ordinates.

In a Domain Driven Design architecture your service often serves to retrieve aggegates from one or more repositories and then co-ordinate calling methods on the aggregate roots to carry out your intent.

One way to see that problems have arisen is if you have what Fowler calles the Inappropriate Intimacy smell between the service and the aggregate root.

Sometimes classes become far too intimate and spend too much time delving in each others'private parts. We may not be prudes when it comes to people, but we think our classes should follow strict, puritan rules.

A good aggregate is a boundary to outside interference, somewhat akin to a facade. If outsiders want something from within the aggregate then they are best of asking the root for it, not drilling into the graph of objects under the root. Watch for using the dot operator to navigate your way into the aggregate as a smell that your service has inappropriate intimacy. That inappropriate intimacy will almost certainly result in domain logic leeking out of the entity and into the service layer

The Inappropriate Intimacy smell is closely connected to the Law of Demeter. Simply put the Law of Demeter says that we can play with our friends but we shouldn't touch their intimate parts. A more complex definition is that we should only call methods on objects that we own, create, or receive as a parameter, not on objects that are returned from one of those 'friends' by a method call or property access.

As an example the code below violates the Law of Demeter, because it chains through from our friend to one of its intimate parts

var options = product.Characteristics.SupportedOptions;

It's likely that we are getting the supported options because we want to perform some business logic with them. It would be better to move the logic that needs those options down to the Characteristics or SupportedOptions level as appropriate.

Sometimes the Law of Demeter is treasted as though the code is more what you'd call guidelines but violation is usually a sign that you are bleeding domain logic through an open wound.

One area of temptation that seems to be catching some right now is the use of LINQ expressions. LINQ expressions can provide you withe a concise and declartive way to iterate over a sequence and perform operations, but they can be tempting to code so that they violate the Law of Demeter, just because you can, pulling domain logic into the wrong location. Consider the above example again:

var matchingOptions = from option in product.Characteristics.SupportedOptions
where option.Code == "Foo"
select new Match {Code = option.Code, Price = option.Price, InStock = option.InStock};

The solution here is to move this logic down on to iterate the list from within Characteristics and provide a method on Option that allows creation of a Match without exposing its details to the caller

If you don't watch for inappropriate intimacy you will find that you end up with transcation scripts in your services. Those in turn lead to duplication, because it becomes hard to find existing funcionality that already provides that feature. Duplication makes our system difficult to maintain because we have multiple versions of the truth which increases the cost of updates and the risk that they disagree as to what the truth is.

Learning some new tools

2009-01-21T22:20:00Z

I an re-writing the London .NET User Group website which is old and long in the tooth. I like these personal projects because they form a great learning opportunity. I can explore new tools and frameworks without worrying about exposing an employer to 'learning on the job'. I have a number of learning goals on this project:

ASP.NET MVC. I am using Monorail commercially and I am looking forward to getting a feel for the differences.
Spark View Engine. I prefer templates that do not obscure the structure of the html and I'm looking forward to taking this one out on the road.
SpecUnit. I have wanted to give an example-driven development tool a run out for a while now as part of efforts to pick up from the BDD guys.
Fluent NHibernate. I'm a Castle Active Record user, but I want to find out if Fluent NHibernate offers me anything more.

I'll probably give some feedback on all of these over the weeks, including fluent NHibernate in my NHibernate series.

Trial and Error

One really interesting idea is Fluent NHibernate's Automapping. Fluent NHibernate is a great example of what is possible with static reflection. However, I found myself a little bit cool on automapping at first. I found it a little hard at first not knowing what the mappings were. I'm used to using Castle Active Record whose close association between attribute and mapped property or class makes this fairly explicit. I have always been less concerned by friction from representing orthogonal concerns as attributes so it took me a while to before I started to enjoy Fluent NHibernate's ClassMap. Automapping pushed my comfort out even further because it was even more 'under the hood'. Getting more comfortable here was a multi-step process.

The first was using the explicit ClassMap files to become confident with the mapping, before tacking automap. Small steps.
The second step was to hook up log4net (a good step with NHibernate anyway). Maybe its just reflex but when I get a persistence error one of the first things I want to do is look at how I was mapping. This meant I could refer to the generated xml for the mapping when I set the logging level to DEBUG. I generate the Db from the domain model using a separate console project I just run from the command line, so this simple step meant I could recover the feedback I wanted as to the mappings from that. That helped me see my mistaken assumptions or confirm that the automap was doing what I wanted.
The last step is to use the built in support for integration testing that the Fluent NHibernate project provides. That gave me confidence that the mapping was what I wanted. James Gregory shows how here.

Finally, I suspect that you may need to be careful if your domain has a lot of exceptions. Exceptions may end up being confusing. I'm not sure that altering the conventions for the mappings that differ may not end up being less confusing than just explicitly mapping in the long run. I suspect there is a trade off here. If most of your classes conform to your conventions and you only have one or two exceptions this may be the way to go, but if you have a lot of variants then this may not be so helpful and you might be better off just using the explicit ClassMap<>.

My one oustanding concern is how people supply automap with criteria for the classes to map from the assembly. Your domain assembly will contain a lot of types which will be transient and not persisted. So you have to provide some selection criteria to pick the types you want to map out of the assembly. The danger here is that to make my selection criteria you might adopt a strategy of deriving from a base class or interface which does not have any value in your domain but is just a 'marker' for persistence. This reduces my adherence to Persistence Ignorance principles because my entity ends up being designed to meet the needs of a mapping technology. I suggest preferring to use criteria such as namespaces here.