Will Beattie's Blog

After completing my Scrum Master course I felt it was high time I review some of our existing engineering practices and consider ways to improve. Whilst we practice strict test-first TDD and have 100% code coverage as part of our “definition of done” the one area that we’ve been missing is automated UI testing and acceptance testing. After all, high code coverage doesn’t mean a thing if the requirements are not met. ATDD & BDD This motivated me to rediscover what is known as Acceptance Test Driven Development or ATDD which is about defining automatable tests from a customer perspective that closely reflect the requirements described in the User Stories . This is also associated to Behaviour-Driven Development (BDD). The cool kids in the Ruby world caught on to this way back when we were still doing web forms development. Some of the Tools available in this space are: RSpec (Ruby) Cucumber (Ruby) Robot Framework (Java & Python)   FITNESSE W...

  Firstly just to clarify I am going to be talking about the OOP Specification Pattern not the data pattern commonly found in the SID (Shared Information & Data) model. Much has been said about the specification pattern so I’m not going to go into that, if you want an overview check out these posts: http://www.lostechies.com/blogs/chrismissal/archive/2009/09/10/using-the-specification-pattern-for-querying.aspx http://devlicio.us/blogs/jeff_perrin/archive/2006/12/13/the-specification-pattern.aspx In this post I’m going to demonstrate how you can make use of the specification pattern to query Entity Framework and create reusable, testable query objects and eliminate inline LINQ queries. The Smell When I first got started with Entity Framework way back in 2008 when EF was still in it’s infancy we had lot’s of inline LINQ all over the code base and specific methods on our repositories for querying requirements (which any OOP purist will tell you is bad). We had ...

Recently I got into a healthy discussion with Keith Patton about Constructor Injection and other such topics to do with Test Driven and Domain Driven Design. One way or another this lead to the birth of Kanda Alpha with the goal of demonstrating best practice domain driven design utilising Visual Studio 2010 Beta, ASP.NET MVC 1.0 and Db4o as the data store. I’ve decided to give an explanation as to the benefits of Mocking and the Test First approach. Mocking quite simply allows you to test components in isolation from their dependencies. By mocking out the results and behaviour of the dependent components you can focus on verifying the behaviour of a single class. Where I’ve found it most useful is in designing the service layer and this is usually the first thing I design after hashing out the Domain Entities. There has also been some comments on Keith’s blog about the purpose of the Service layer if all it is doing is acting as a Facade to the Repository. This is a...

Keith Patton has started a CodePlex project called KandaAlpha which I will be contributing to. Original post here The aim of the project is get our feet wet with Visual Studio 2010 Beta 1 and in particular the POCO capabilities of Entity Framework. It's also going to try and demonstrate best practice Domain Driven Design and other associated patterns. db4o has been selected as the persistancy database of choice as it presents a very interesting alternative to the standard RDBMS.