One of the things we try and do is always keep our site up, sounds simple right? One way to achieve this is to have a good caching policy.
Here's what we do:
Cache a response from some external service (be it a db or web service, whatever)
When a user request the resource ALWAYS serve it from cache if it's there
Then "out of band" (i.e. on a different thread) make a call to get it from the external service and update the cache if you get a valid response.
But only do this if the cache is stale
Simple right? That way if your external service goes down you can still serve it from cache. Your user will always get the fastest possible response (i.e. they wont be the sucker who has to go and get it). And your service remains up as much as possible.
A double-entry bookkeeping system is a set of rules for recording financial information in a financial accounting system in which every transaction or event changes at least two different nominal ledger accounts.
At it's simplest you have two ledgers when you make an account transaction you make an entry in both ledgers. Then at the end of the month you reconcile these two ledgers and they should be the same. Essentially from an accounting point of view we're saying that by using two different ways of doing something we come to the same answer.
Why is the useful from a TDD perspective?
Well you should be using different ways to make your assertions from your implementation, particularly when you talk about integration tests.
Lets say your writing some integration tests for a repository. Lets say you're using Simple.Data to access your database. Your tests should then use something else. You should probably get as close to the metal possible. In this case you should probably use the SqlCommand class.
Put some data in your database using SqlCommand. Then assert that you can retrieve it using Simple.Data.
That way you are making a Double Entry Assertion in your tests. The chances of both systems being broken in the same way are reduced.
We've spent a lot of time recently on fixing up our automated feature tests (AATs). The problem has been that these failing tests have blinded us to real problems that have crept into live systems. The usual answer is to 'just run them again' and eventually they go green. The main problem is our attitude to the tests, we don't respect them and we don't listen to them, as such they provide no feedback and are completely pointless. The response to broken feature tests would normally range from the test environment is down, the data is in contention, the database is down etc etc, but never something I've done has broken something.
So what is the solution?
We improved the reliability of the tests that we could and removed the ones we couldn't. Now you may think this is a bit of a cop out, but the amount of feedback we were getting from the tests was negligible. The best think you can get from your tests is something you don't expect. you should expect them to pass and be surprised or shocked when they don't.
Stop the line and fix the problem. Don't just keep running them again.
The following details concepts that have been adopted on the site I'm currently working on. This was born out of a discussion that took place among the devteam at the time. Differences in phraseology and meaning were ironed out to come up the following definitions and responsibilities.
Queries(GET)/Commands(POST)
* Contain all the information required to perform an action.
* Data should be bound onto the query before it hits the controller action.
* They are POCO and contain no logic.
Controllers
* Marshall request to handlers and mappers
* Creates the view model from the handler result
Handler
* Process queries/commands
* returns various types (Model/Entity/API DTO)
View Models
* Contains data that you are using in the view, should not expose anything other than view models/value types.
View
* Stuff you show the user, should only contain logic that is required to get the stuff displaying correctly.
Wrappers
* Wrap calls to external api
Services
* Do things that aren't simple, pull together bits and bobs and package them up. Take care of business logic that have cross cutting concerns.
Mappers
* Mappers simply convert one object to another. They DO NOT perform any other logic.
Charts Example from http://www.7digital.com/b/charts
ArtistChartController
* Takes the query from the web request (which has been bound in the pipeline)
* Passes the query to a handler
* Maps response from handler to view model using auto mapper
ArtistChartQueryHandler
* Takes the query
* Does some work to get some configuration options
* Builds up the query further to execute against the API wrapper
* Returns API DTO
Api Wrapper
* Takes query
* Executes against external API
* Parses responses and maps into API DTO object
One of things I wanted to do the other day was resolve an open generic interface. Or more specifically resolve a generic type at runtime.
This is what we came up with:
var argumentsAsAnonymousType =
typeof(IHandler<>)
.MakeGenericType(instance.GetType());
var concrete =
IoC.Container.Resolve(argumentsAsAnonymousType);
The first problem was resolving an open generic type, this was solved using MakeGeneric. This returns a type object which you can pass to windsor to resolve for you.
But now you're left in a situation where you don't know what the returning type is. You could use reflection to call the method. The good thing about this is in the type you're declaring you can afford to use a generic type.
public interface IHandler<T>
{
void Handle(T instance);
}
public class FileNotFoundHandler : IHandler<FileNotFoundException>
{
public void Handle(FileNotFoundException exception)
{
_logger.Warn(fileNotFoundException.FileName)
}
}
The downside is, you're using reflection! The alternative is to use a non generic interface and utilize interface inheritance.
public interface IHandler<T> : IHandler
{
}
public interface IHandler
{
void Handle(object instance);
}
public class FileNotFoundHandler : IHandler<FileNotFoundException>
{
public void Handle(object exception)
{
var fileNotFoundException as FileNotFoundException;
_logger.Warn(fileNotFoundException.FileName)
}
}
That way when you resolve the handler you can cast it.
var argumentsAsAnonymousType =
typeof(IHandler<>)
.MakeGenericType(instance.GetType());
var concrete =
IoC.Container.Resolve(argumentsAsAnonymousType) as IHandler;
concrete.Handle(exception)
The benefit now is that you don't need to use reflection. The down side is that you need to unbox your object inside the handler, however this shouldn't be an issue as you've already guaranteed the type when you resolve the object.
