Features and unit tests
This post has been imported from my previous blog. I did my best to parse XML properly, but it might have some errors.
If you find one, send a Pull Request.
Currently I’m involved in a greenfield project, which was happy enough to start as a event-sourced DDD. The paradigm fits well the domain, but there is some cost of zero-iteration which is being paid now. The cost is a small infrastructure which has to be provided to be wrap the domain. It’s really small (maybe not that small), but has to be tested. To make it simple/complex I’d add that it consists of a few functionalities/modules, each providing and consuming some contracts. So what about testing?
Recently I re-read a Kozmic’s blog entry, which covers a very interesting problem of unit tests vs ‘real life scenarios’ as well as ‘Concepts and features’ written by Ayende. It made me think a lot about the new application and t he way I tried to test it. I took the first module, which had a small test base written in a not-good-as-it-should-be manner, deleted the tests and started to implemented sth new.
I know that some people have opinion ‘no container in your tests’, but in tests of the infrastructure? Come on, this is all about matching all the pieces of the code you wrote! Nevertheless, having the WindsorInstaller of a specific part of the application I initialized the container, added one stub for the external dependencies and fully configured this part of the application. All the tests used the enpoints provided by the whole functionality and it worked like a charm. It seems that the number of test fixtures will be equal to the number of functionalities/modules the infrastructure provide. I find it a quick, simple and powerful solution for having it testes. What about the unit tests? If I have some infrastructure class longer than 100 lines and plenty of methods in there, I will go for unit tests, but for now, this paradigm works like a charm.
