Showing posts with label DSL. Show all posts
Showing posts with label DSL. Show all posts

Sunday, December 21, 2008

Test Data Builder

In every project you reach a point where you need test data for unit testing. Having a reasonably complex domain model can make this task "difficult" because testing an entity in many cases means that you also have to setup associations to other entities. Intializing objects per test is cumbersome and any changes to constructor arguments will break your tests. One of the solutions to this problem is to use the Object Mother pattern. It's basically a class with factory methods that helps you setup an object for testing. The object creation code is moved out of the tests so that it can be reused and making the test data more maintainable. So if you are developing a scrum application and want to create a project with a sprint and a user story you would do something like this:

public static class ProjectMother
{
 public static Project CreateProjectWithSprint()
 {
     Project project = new Project();
     Sprint sprint = new Sprint();
     UserStory userStory = new UserStory();
     userStory.Name = "User story";
     userStory.StoryPoints = 8;
     sprint.AddUserStory(userStory);
     project.AddSprint(sprint);
     return project;
 }
}

Project project = ProjectMother.CreateProjectWithSprintAndUserStories();
However as time goes by you end up with a lot of factory methods for the slightest variation in the test data beacuse of the heavy coupling that exists since many tests use the same method. This make the Object Mother class hard to maintain. To solve this problem I usually write a fluent interface (embedded domain specific language) that I use to initalize my objects for testing. This is heavily based on the Expression Builder pattern. For each class I want to test I write a builder for that class. So when I want to create a Project object I just write:
Project project = ProjectBuilder.Create.Project
              .WithName("Test Project")
              .WithSprint(SprintBuilder.Create.Sprint
                  .WithName("Sprint 1")
                  .WithUserStory(UserStoryBuilder.Create.UserStory
                      .WithName("Story 1")
                      .WithStoryPoints(13)
                      .WithTask(TaskBuilder.Create.Task
                          .WithName("Task 1")
                          .WithHours(3))));

Behind the scenes the ProjectBuilder takes care of everything adding sprints and so on. In each method the builder just returns itself after having done some setup on the private Project instance. The ProjectBuilder is finally casted to Project using an implicit cast operator which returns the private Project instance.
public class ProjectBuilder
{
 private static Project mProject;

 public static ProjectBuilder Create
 {
     get { return new ProjectBuilder(); }
 }

 public ProjectBuilder WithName(string name)
 {
     mProject.Name = name;
     return this;
 }

 public ProjectBuilder Project
 {
     get
     {
         mProject = new Project { Name = "Test Project" };
         return this;
     }
 }

 public ProjectBuilder WithSprint(Sprint sprint)
 {
     mProject.AddSprint(sprint);
     return this;
 }

 public ProjectBuilder WithBacklog(Backlog backlog)
 {
     mProject.Backlog = backlog;
     return this;
 }

 public static implicit operator Project(ProjectBuilder builder)
 {
     return mProject;
 }

}
Still, I don't feel that the Object Mother and the Builder are mutually exclusive. If I have a lot of tests that use the same test data I often create an Object Mother with a factory method that uses the builders. When I need a specialized initialization of an object for a test I just use the builders directly in my tests.

I find this way of creating test data really useful and hopefully you do too! Feel free to download and use the code. The builders are located in the tests project.

Merry Christmas!!

Tuesday, March 4, 2008

The next generation rule engines are pure C#

The project I'm currently working on is based on a rather narrow domain, but with a high density of business rules that comes along. Currently we are writing the rules directly in code, but there have been some pressure about using an in house created XML based rule engine. As the rule base becomes bigger and bigger the more the pressure. As I see it there are two reasons for using a rule engine:
  1. Separate the rules from the code so it can be edited without recompiling the application.
  2. Let the rules be edited by a domain expert.
Does an XML based rule engine support this? Sure, a rule engine certainly separates the rules from the code and makes it editable. However, I don't really see how rules in XML are much better than rules written in code. Rules in XML can certainly become as complex syntactically as code and I would argue that as the rules get more complex, rules written in code actually get more easy to read and understand. So at my point of view a rule engine doesn't provide a domain expert much more support in editing rules than plain code. Now comes the real pain with a rule engine; Testing. As the rules are written in XML it becomes real hard testing them incorporating your domain objects. Sure, the XML is often used to generate code, but I don't see how this improves the testability much. The generated code will normally be complex and hard to use as the XML and code generator tries to capture and provide functionality for general purpose problems and scenarios in non specific domains. Refactoring the code won't update the XML and suddenly you find yourself in a maintainability hell. This is why I would rather have my rules in code. Now the problem with writing rules in code isn't that it is impossible to separate the rules from the rest code. Writing rules in code suffers in the same matter as rules written in XML in that it is extremely hard for a non technical domain expert to read, edit and verify rules. Lets not forget create new rules. I can understand those who argue that rules in XML are more maintainable for a non technical than rules in code, and the fact that there are some stakeholders driven against a XML based rule engine really got me thinking. As I most certainly want to keep my business rules in code for testability and maintainability I started thinking about an alternative way that could let us keep the rules in code and at the same time make them easy to edit, which in turn would satisfy all parties. A couple of days ago, on my way to work, I was talking to a colleague who had attended a meeting at the Norwegian .Net User Group (NNUG) where Anders Norås, a former employee at my company held at talk about fluent interfaces and domain specific languages. I immediately associated this concept with my rules problem and started digging around on the Internet. In my search I found at great article by Anders Norås where he shows an example of an DSL implementation. I would also recommend an article by Martin Fowler where he discusses the pros and cons of internal and external DSLs. Although external DSLs can be evaluated at runtime, which has made XML so popular, and the fact that internal DSLs are limited by the syntax of the language of choice, I would still go for an internal DSL. I don't have to learn a new language and I can take advantage of my existing skills. The idea of fluent interfaces seems very interesting. Writing a fluent interface would mean that the domain expert editing the rules could use IDEs and even get intellisense while he/she is typing the rules. Writing the rules in a language like Boo, which runs on the .Net CRL could even let the rules be evaluated runtime. However, I don't see this as an requirement for my problem. Writing a fluent interface in C# would probably satisfy all my needs. Extension methods would most certainly become handy. Still, I'm a little bit concerned about the effort and cost of creating such a DSL. Hopefully I soon will find the time to implement a little prototype and write a part 2 of this post. I'll keep you posted!