Incremental development with Monorail: Part Five
Welcome back. In this post I’ll be getting our tests passing again and cleaning things up a little. We left off with a failing integration test:
I suspect this is due to the IBlogPostMapper dependency we introduced to our BlogPostService not being handled by the container. If we run in the browser we can confirm this is in fact true:
As we’ve yet to implement our IBlogPostMapper we must go ahead and do this before we can add the container configuration to pass our integration test. Lets bust out a test and get things rolling:
We have a few blanks to fill in in order to get this to compile and run:
- Make the DTO’s properties virtual so we can mock them. This is in preference to extracting an interface.
- Implement IBlogPostMapper.
- Add the necessary properties to the IBlogPost interface.
Lets go ahead and do this now:
IBlogPostMapper minimal implementation:
The necessary modifications to IBlogPost:
Now we can compile and run our test:
Our BlogPostMapper implementation is throwing an exception so lets go back and take another step to try and pass our test:
BlogPost:
I’m pretty certain we’ve done enough to pass our test now. Lets have a go:
OK now lets focus on the full suite:
Our integration test is still bombing but as we’ve got a mapper now, we can go ahead and wire up our Windsor configuration and get things moving again:
We’ve added another configuration file: mapper.config and referenced this from the web.config. We shouldn’t need to do any more than this so lets run our full test suite:
Our full suite is passing now. Not bad for 5 minutes work! As usual the latest changes are checked in to the Google code project hosted here.
Now we have a full passing suite, in our next edition I’ll be moving down into the persistence and also incorporating a few modifications from Hammett. Stay tuned!
Hi Ben,
Thanks for those great articles
Would you agree that I post french translations of them on my blog ? With credits to you of course
Cheers,
Gildas
Gildas
April 25, 2008 at 8:30 am
Hi Gildas, thanks for your comments. You can post translations of any of the content here, I just ask you link back to the original post. Let me know when you’re done and I’ll link to you from here.
benl
April 25, 2008 at 10:28 am
hi there:
I think this is a great series of article, please keep it up, and the way you explain things is fantastic very simple and thorough
would you not agree that it s a good idea to add a BaseController where you do your CRUD
something like:
public class ControllerCRUD : SmartDispatcherController
{
public void List()
{
}
public void Add()
{
}
}
and then you inherit from that all your controllers?
also, do you think is a good idea to “add” the way you are adding?
if you are planing to use persistence and I m pretty sure you are going to be using AR for it is all that structure necessary?
Cheers
Andrea
Andrea
April 25, 2008 at 4:19 pm
Hi Andrea,
Yes of course once there are other controllers I will probably extract a common base class for this kind of functionality. However, you’re missing the point of my approach. At this stage we’re not making any assumptions about what we (think) we need, we’re doing the most simple steps to pass our tests. The common parlance for this is YAGNI or “you aren’t gonna need it”.
Of course, since we have a good suite of tests, we can confidently make these refactorings later when we need to. That is the whole point of TDD and the approach i’m taking! Thanks for your comments.
BenL
April 25, 2008 at 4:31 pm