One place where we recently used what I consider to be a seam was to remove calls to external sites from our application when we were running our tests against the application in our normal build.

We don’t have any control over these dependencies as they are completely external so we made calls to those urls go to localhost instead by adding an entry in our hosts file (C:\WINDOWS\system32\drivers\etc) like so:

On our UAT and production servers further down the pipeline we don’t have that type of setting in the hosts file so those run against the real dependencies.

I think the ideal place to apply this seam would be in a configuration file where you would be able to configure dependencies but in this case the dependency is actually added in outside of our team’s control so we decided to adjust the behaviour where we could albeit a bit further away from where the behaviour is than we would have liked.

Another area where we might make use of seams in our systems is in the creation of what my colleague Julio Maia refers to as 'impersonators'.

Impersonators are little pieces of code that we write to impersonate 3rd party systems we need to integrate with - ideally we would have an impersonator for every integration point and we can make use of these impersonators at certain stages of our build rather than always having to call the real end point.

One example of an impersonator that we’ve used recently is a proxy which captures requests and responses being made to a service layer from our application and then just replays these back every other time the same requests are made.

The ideal place for this seams to be triggered (i.e. the seam’s enabling point) is in a configuration which is independent of our production code and therefore allows us to choose when we want to make use of the impersonator and when we need to use the real service.

In our case we have the endpoint defined in our 'web.config' and a step in our build process generates versions of that file for each of the environments that we might run our application in.

We can then change the 'service.Endpoint' entry to point to the proxy for our development environment but have it point to the real service layer for other environments.