Sean Chambers

‘Vice’ Testing

schambers — Wed, 22 Apr 2009 03:55:00 GMT

Refactoring to tests is no easy task. The largest problem that you run into is moving around code with no feedback as to whether you are breaking modules other than doing very high level user/functional testing directly against the UI. This makes the first step of refactoring to tests the most difficult to take.

Before I begin describing the technique at hand I would like to prefix it with a disclaimer and a warning: DO NOT use this to replace actual unit tests. This type of testing should ONLY be used as a baseline so that you can start to do larger refactorings that could potentially break portions of code. This gives you the start of a safety net, albeit a pretty flimsy one.

Awhile back Joe Ocampo mentioned a technique that Michael Feathers called ‘vice’ testing. I recently came across an article on infoq where Ian Roughley calls it Logging Seam Testing. At the core, it’s the same thing just named a little differently. The article on infoq is in java, so I created a utility to do the same thing in c# that you can find in my github repository here. Here is a direct download link to a zip archive.

This is quite the interesting technique. One thing to note: I have yet to use this technique myself, so please take it with a grain of salt. Seems like this could work well for extremely tightly coupled, monolithic code and wouldn’t necessarily fit for every scenario. I could see this being a good fit while trying to reduce cyclomatic complexity or breaking large methods/classes into smaller ones. That being said, let’s dive in.

The basic idea here is you want to get some form of tests into your code, but it’s much too difficult to break dependencies and create seams to get unit tests in. That’s where vice testing comes in. It’s actually very simple and straightforward. The process goes like this.

Determine what it is that you want to test, in this sample its the amount of deductions and the amount paid to an employee via an Employee.Pay method
Insert logging statements in your production code that simply log internal state of an object. In the example it is deduction total, salary and ‘completed’
Write a test that sets up the class under test, intializes the log4net logger, sets the expectations to be met
Execute the method on the class under test and assert that all expectations were met via the ViceAppender class

First let’s look at the actual test code that would do the work for us:

   1: [TestFixture]

   2: public class EmployeeTests

   3: {

   4:     private ViceAppender _viceAppender;

5:

   6:     [TestFixtureSetUp]

   7:     public void TestFixtureSetUp()

   8:     {

   9:         _viceAppender = new ViceAppender(new log4net.Layout.SimpleLayout());

  10:         log4net.Config.BasicConfigurator.Configure(_viceAppender);

  11:     }

12:

  13:     [Test]

  14:     public void employee_is_paid_expected_amount()

  15:     {

  16:         _viceAppender.AddVerification("deduction total=" + 70m);

  17:         _viceAppender.AddVerification("salary=" + 330m);

18:

  19:         IList<decimal> _deductions = new List<decimal>();

  20:         _deductions.Add(50m);

  21:         _deductions.Add(20m);

22:

  23:         var employee = new Employee(400m, _deductions);

  24:         employee.Pay();

25:

  26:         _viceAppender.PrintExpectations();

  27:         Assert.IsTrue(_viceAppender.Verify(), "Expectations not met");

  28:     }

  29: }

In the example you can see that I am initializing a log4net logger and setting some configuration on it. Then you setup verifications on the ViceAppender class that matches expectations added to your class along with the expected internal state that will result from the input.

Here is the Pay method from the Employee class:

   1: private ILog _log = LogManager.GetLogger(typeof(Employee));

2:

   3: public void Pay()

   4: {

   5:     // bunch of code outside the scope of this test

6:

   7:     foreach (var deduction in _deductions)

   8:         _salaryPerWeek -= deduction;

9:

  10:     _log.Info("deduction total=" + _deductions.Sum());

  11:     _log.Info("salary=" + _salaryPerWeek);

  12:     _log.Info("completed");

13:

  14:     // more code we don't want to test right now

  15: }

Now that we have the expected output, you can now assert what was dumped to a log file and determine if your tests are passing or not. This is achieved pretty easily with a simple Expectation class and a derived Appender class that is called ViceAppender. We have a ‘Verify’ method here that will iterate over the logging statements using the message as a key and see if the expected message is actually in the logger. The verify method returns a boolean to indicate if all expectations were met during the test run. The message is used as the key on a dictionary. Therefore the message needs to match exactly in order to match an expectation.

   1: public bool Verify()

   2: {

   3:     bool result = true;

   4:     foreach (string key in _verifications.Keys)

   5:         if (!_verifications[key].WasCalled)

   6:             result = false;

7:

   8:     return result;

   9: }

Also on the ViceAppender I have the PrintExpectations() method that outputs the expectations to the Console:

   1: public void PrintExpectations()

   2: {

   3:     foreach (string message in _verifications.Keys)

   4:     {

   5:         var sb = new StringBuilder();

   6:         sb.Append("Logger called '")

   7:             .Append(message)

   8:             .Append("'. Was Called? '")

   9:             .Append(_verifications[message].WasCalled)

  10:             .Append("'");

11:

  12:         Console.WriteLine(sb.ToString());

  13:     }

  14: }

Produces the following output:

   1: Logger called 'deduction total=70'. Was Called? 'True'

   2: Logger called 'salary=330'. Was Called? 'True'

The benefit from doing this type of testing is no modification of the class under test needs to take place. All you need to add is logging statements and a field for getting at the ILog instance. This gives you a solid foundation to begin doing refactoring.

This could be viewed as integration tests as well as unit testing because your class under test may leak into other portions of code. Make sure you make your scope of your test as narrow as possible to combat the problem. This is a good place to start, but use wisely. It’s not meant to be a long term solution and can be abused just like any other technique.

After typing out some code and playing with it for awhile, You could get this to work without even using a logging utility and just make one yourself. The java example on infoq used the java equivalent of log4net so I did the same here. One other thing I left out was that Ian in his infoq article had the ability to assert on expectations that were called when not expected. While this is a good feature, I decided it was a little overkill for a simple example and left it out for brevity.

TDD Firestarter

schambers — Mon, 19 Jan 2009 02:26:00 GMT

I want to thank everyone for coming out to the TDD Firestarter event that we had in Tampa yesterday. We had an excellent turnout (about 80 people), and everyone was very interested in getting to know TDD/BDD.

We are in the process of post-processing videos and getting the content together. We have complete videos of the entire presentation as well as presentations in breakout rooms after the main workshop. Expect the content to be posted later in the week.

I also want to thank everyone that helped with directing the video, answering questions and doing presentations in the breakout sessions. We couldn't have done it without your help!!

Starting with BDD vs. starting with TDD

schambers — Sun, 07 Dec 2008 14:37:00 GMT

Yesterday I did a presentation on TDD/BDD at the Tamp Code Camp. I have done several TDD presentations in the past but this was the first time I also showed the attendees BDD at the same time. In actuality I didn't even show them a traditional TDD test. Not to my surprise, newcomers seem to grasp BDD much quicker and easier than from a TDD perspective. I did touch on that some tests would still be driven from a technical aspect, but from a business requirements they should try to use BDD. Another thing I very briefly touched on was Mocks/Stubs. I try not to go too in depth as you can discuss mocks and stubs for an hour by themselves and isn’t worth it to dive into when all you have is an hour.

The best description I came up with for what is "BDD", it's nothing more than two things:

A language shift in traditional TDD
Driving your tests from a domain/user story perspective rather than technical perspective

When this was explained to a group of people that have never even used TDD, their heads nodded and I saw about 30 lightbulbs come on in the room. They just seemed to "get it" right away.

As I dive further into a description here. I should note that there is ALOT of differing opinions on what the proper way to do BDD is and what the proper “language” is. Much like TDD, it comes down to personal preference. Using a simple BDD tool like SpecUnit helped me a lot to figure out how to structure my tests in the beginning. From there, It breaks down to what you find works.

SpecUnit lays a pretty good foundation on what your language is. Let’s take a look at the language real quick. We’ll compare traditional TDD test naming vs. BDD test naming. Here’s how you would layout a test class and test for an AddressBook application with traditional TDD:

[TestFixture]

public class addressbook_tests

    [SetUp]

    public void SetUp()

        // setup code for test

    [Test]

    public void can_add_person_to_addressbook()

        // test assertions

As you can see. We have TestFixture/Test attributes. This is pretty straightforward and if you’ve been doing TDD you know how it works. Now let’s look at the same test using SpecUnit and with BDD language adjustments:

[Concern("Address Book"), TestFixture]

public class when_adding_a_person_to_an_addressbook : ContextSpecification

    [Context]

    protected override void  Context()

        base.Context();

        // setup code for test

    [Observation, Test]

    public void addressbook_contains_person()

        // test assertions

Its a minor shift but a couple of things are important here.

I have both Concern/TestFixture and Observation/Test attributes on the class/method. This reason I am doing this is because I am using Resharper. At the moment, resharper doesn’t recognize that Concern/Observation derive from TestFixture/Test and thus needs to be added so the Resharper test runner recognizes the tests. I have filed a bug with JetBrains and this will be fixed on the next release. It also helps to show what was a testfixture and test in the first example
Instead of [SetUp] attribute you now have the [Context] attribute.
There are other methods you can override from ContextSpecification like “Context_BeforeAllSpecs”, “Context_AfterAllSpecs” and so on.
SpecUnit has a number of extremely useful extension methods that make for a much more readable assertions like: somevalue.ShouldEqual(“whatever”).

In BDD one of the biggest shifts is that your testfixture classes are now grouped together into “Concerns” and your classes are broken out into Contexts. So in the TDD example our individual tests defined the context, now we pull that context up to the class level and the tests then become the acceptance criteria for the context.

BDD has a much better alignment with business concerns and allows us to create tests that are parallel with User Stories/Acceptance criteria. This allows us to write software that is directly inline with what our stakeholders want rather than writing code that may or may not be necessary.

Moving on, lets look at another important part of BDD which has to do with reusing contexts in your tests. Ok, so lets say we are creating an addressbook in our “when_adding_a_person_to_an_addressbook” like so:

[Concern("Address Book"), TestFixture]

public class when_adding_a_person_to_an_addressbook : ContextSpecification

    private AddressBook addressBook;

    [Context]

    protected override void  Context()

        base.Context();

        addressBook = new AddressBook();

Now lets say we have another user story and we have to create another context for “when_searching_for_a_person_in_an_addressbook”. Instead of creating a class with a context setup that matches the one above, we want to enforce DRY and create a “behaves_like_addressbook” class that both test classes can utilize:

public class behaves_like_addressbook : ContextSpecification

    protected AddressBook addressBook;

    protected override void Context()

        base.Context();

        addressBook = new AddressBook();

Now both of the context test classes can derive from this class like so:

[Concern("Address Book"), TestFixture]

public class when_adding_a_person_to_an_addressbook : behaves_like_addressbook

[Concern("Address Book"), TestFixture]

public class when_searching_for_a_person_in_an_addressbook : behaves_like_addressbook

So now any setup of the context that our classes share can be placed in the behaves_like_addressbook “Context Base class”. This is a part of bdd that comes from rspec. The ruby guys reuse their contexts in exactly this way. Then if you have additional context base classes along the way if you have two or more contexts that share behavior/setup. For instance. lets say we had a shared context further down we can set it up like this:

public class behaves_like_address_book_with_some_other_context : behaves_like_addressbook

    protected override void Context()

        base.Context();

        // modify our context that was

        // created in behaves_like_addressbook

This really helps to promote reuse among the context setups in your tests. Also take a look at the SpecUnit.report.exe in the specunit project. It allows you to generate an html document from the name of your tests to hand to stakeholders. Very useful form of documentation.

Thats it for an introduction to bdd and to get the gist of it. Now heres a list of resources to get you started not only for the people that were in my presentation yesterday but also for any newcomers to BDD.

SpecUnit : BDD testing tool that was described in this post

schambers googlecode : My google code repository with my resharper templates and AddresBook sample for BDD

AutoHotKey : install this and execute the “TestNamingMode.ahk” from my google code repository, then you do crtl+shift+u to turn on test naming mode where spaces are turned into underscores for you. Thanks to jpboodhoo for this!

Jean-Paul Boodhoo’s Blog : this guy is a BDD master. He has excellent posts on BDD and if your not already, you should definately read his blog.

JetBrains ReSharper : alot of the people in my presentation were blown away when I showed them what resharper was capable of. For anyone that is interested you can obtain a 30-day trial

Any feedback would be greatly appreciated! till next time

PTOM: The Decorator Pattern

schambers — Mon, 17 Nov 2008 04:23:00 GMT

For the month of November, Pablo's Topic of the Month is Design Patterns. I will be talking about the Decorator design pattern in this post.

The Decorator Pattern was originally coined by The Gang Of Four (GoF). It is a commonly used pattern for extending functionality dynamically at runtime. This is in contrast to a common OOP technique that everyone knows called inheritance. At it's most basic level, think of the Decorator pattern as a wrapper with the intent to modify/attach additional behavior to an underlying class.

This is one of the easiest patterns to grasp and understand, as well as to put to use. We will use an example of a coffee shop, let's start with a class that is used to represent a cup of coffee available in the shop. Here we have the ICoffee and Coffe interface and class:

public interface ICoffee

    string Name { get; }

    decimal Total { get; }

public class Coffee : ICoffee

    public string Name

        get { return "Coffee"; }

    public decimal Total

        get { return 0.75m; }

We have an interface that defines behavior for a cup of Coffee, and then we have a concrete class that represents a Coffee. Something to take note of here is the fact that the GoF sample uses an abstract base class for Coffee instead of my ICoffee interface. The abstract base class is then also used when implementing the decorator pattern. In other samples, people use interfaces instead of ABC's, I usually opt for interfaces to start and then refactor to ABC if it is warranted. Use your judgement here. This is a pretty basic example so an ABC isn't really needed.

Now let's say we want to add the ability to have a customer add an extra shot of espresso to their latte. Normally you would do this with traditional inheritance like so:

public class CoffeePlusEspresso : Coffee

    public new decimal Total

        get { return base.Total + .5m; }

    public new string Name

        get { return string.Format("{0} w/ Extra shot of espresso", base.Name); }

This would work, however it's not very desirable. Eventually as you add more and more permutations, (Coffee w/ Espresso, Coffee w/ Espress and Whip cream, etc..) it would lead to a class explosion and you would have a new class for every new combination of ingredients someone could have for a cup of coffee. A better option would be if we could add or "decorate" the original cost and name with our added options. Enter the Decorator Pattern.

The first step in implementing the decorator pattern is to define an abstract base class that all of your decorators can derive from. This helps enforce the DRY principle by having the code that implements the ICoffee interface. Commonly, this ABC will only be calling the passed in or "decorated" object. This way, you only need to extend the properties/methods you want in the decorators and eliminates the need to return the decorated properties/methods in each decorator.

Here is our base class that I have called IngredientDecorator:

public abstract class IngredientDecorator : ICoffee

    protected ICoffee _decoratedCoffee;

    protected IngredientDecorator(ICoffee decoratedCoffee)

        _decoratedCoffee = decoratedCoffee;

    public virtual string Name

        get { return _decoratedCoffee.Name; }

    public virtual decimal Total

        get { return _decoratedCoffee.Total; }

As you can see here, our base decorator implements the ICoffee interface by just calling the underlying ICoffee properties that we passed in the constructor. Very simple and to the point. Now we can start to create our concrete decorators that will extend the behavior of our Coffee class. Lets start with our original Espresso example and create an EspressoShotDecorator class.

public class EspressoShotDecorator : IngredientDecorator

    public EspressoShotDecorator(ICoffee decoratedCoffee) : base(decoratedCoffee)

    public override string Name

        get { return string.Format("{0}, shot of espresso", base.Name); }

    public override decimal Total

        get { return base.Total + 0.50m; }

We can now create a Coffee instance, pass it to an EspressoShotDecorator and print out the grand total and modified name by calling EspressoShotDecorator.Name/EspressoShotDecorator.Total as shown here:

Coffee plainCoffee = new Coffee();

EspressoShotDecorator espressoShotDecorator = new EspressoShotDecorator(plainCoffee);

Console.WriteLine("Name of your coffee: {0}", espressoShotDecorator.Name);

Console.WriteLine("Cost: {0}", espressoShotDecorator.Total);

// Name of your coffee: Coffee, shot of espresso

// Cost: 1.25

This is where it starts to become really flexible. Let's say we also have a "Whip Cream" topping that we want to add as an ingredient. To add this functionality to our application, all we need to do is create a class that represents that single item and we can then begin to chain together the options when someone is asking for their cup of coffee with additional options. The options they have are now interchangable and dynamic. Here is the WhipCreamDecorator:

public class WhipCreamDecorator : IngredientDecorator

    public WhipCreamDecorator(ICoffee decoratedCoffee) : base(decoratedCoffee)

    public override string Name

        get { return string.Format("{0}, whip cream", base.Name); }

    public override decimal Total

        get { return base.Total + 0.25m; }

Adding this to the mix and then chaining it on top of the EspressoShotDecorator would yield the following results:

WhipCreamDecorator whipCreamDecorator = new WhipCreamDecorator(espressoShotDecorator);

Console.WriteLine("Name of your coffee: {0}", whipCreamDecorator.Name);

Console.WriteLine("Cost: {0}", whipCreamDecorator.Total);

// Name of your coffee: Coffee, shot of espresso, whip cream

// Cost: 1.50

You can now see how this can be flexible in dynamically modifying and extending behavior at runtime. If you want to be really cool, you can hook up the classes to an IoC framework and chain together these objects through a configuration. This is even more flexible than the above approach because you could modify behavior by changing your configuration for the IoC framework. An excellent example of this was already posted by Alex Henderson (a.k.a The Bitter Coder) in his series on Castle Windsor tutorials

As you can see the Decorator Pattern is a powerful, easy to use/implement, flexible design pattern that should be in everyones arsenal. Please post comments any derivations that you have found useful of the Decorator Pattern. Till next time!

LosTechies welcomes Colin Jack!

schambers — Thu, 23 Oct 2008 10:49:00 GMT

Today the LosTechies family welcomes Colin Jack to the site. Colin is a very active member in the ALT.NET and .NET Community. Colin resides in Edinburgh, UK. So please take a moment and welcome Colin to the family! Welcome Colin! We look forward to insightful posts!

New job, new opportunities at Telligent

schambers — Mon, 15 Sep 2008 23:07:00 GMT

Over the last couple of months I have been casually looking at the job market in the Jacksonville/Orlando area at various opportunities. None of the really interested me and had mediocre opportunities at best. I was comfortable in my current job, but was looking for more of a challenge. Eventually, I came to the conclusion that in order for me to continue to gain knowledge and strive for more experience, I needed to seek a new position with a strong development background; among many other reasons at the time of making these considerations. I felt the stench of stagnation, and in the development community everyone knows that stagnating is not where you want to be as stagnation == dead in the programming world.

I saw that Nate Kohari (author of Ninject) had just recently accepted a position from Telligent, and one thing led to another, I sent off my resume to Scott Watermasysk and started the interview process at Telligent. After a very thorough interview process I accepted a position at Telligent as a Senior Software Development Engineer. I am extremely excited to start with a company on the rise like Telligent and eager work with a notable and knowledgable staff that is present at Telligent. I am looking forward to new challenges, new technologies and working in a new environment. I will be telecommuting from my home in Florida for this position which should present some new challenges in itself.

I will miss everyone that I have worked with at the School District over the years, and will stop in from time to time to say hello. Comfort zones are meant to be broken and any decent developer will always be striving for different challenges to overcome and new opportunities. Once you reach the top of one ladder, the only logical step is to look for the next one and continue climbing.

Refactoring towards deeper insight

schambers — Sun, 24 Aug 2008 14:03:00 GMT

While giving my DDD presentation at the Jacksonville Code Camp, I felt that DDD refactoring was one area that I really didn't touch on enough. I mentioned it briefly but I wanted to build on the discussion that we started to have in the presentation. I feel this is a very important practice of DDD and needs more explanation.

When doing DDD, a very important concept is the fact that noone gets the model correct the first time. This is against the traditional waterfall approach of BDUF (big design up front) and trying to set everything in stone from the beginning. Because of this reason, the domain model needs to be refactored throughout the development lifecycle. In order to support this constant refactoring, you need to use TDD in order to keep your model functioning as expected. Without the safety net of tests, you have no way of seeing how the changes impact other portions of the system.

In my presentation I spoke about two areas of refactoring in relation to DDD, or refactoring in general. Timing and Intiation. There are other concepts surrounding refactoring that I won't focus on here.

Timing of refactoring deals with when refactoring should occur during the development. Refactor too early and you will spin your wheels, wait too long and it becomes difficult to change the model and more costly. There is a sweet spot for timing to perform refactoring. I would say its a fairly large window as you will start to get code smells, this is an indicator that refactoring needs to occur, along with the ubiquitous language changing. The refactoring timing is fairly easy to see and show take place once you see it coming. Don't hesitate or put it off until later, it will hurt much more if you do.

Initiation of refactoring is important as well. Once you notice that refactoring needs to take place the second step is actually initiating the refactoring. It's extremely easy to start cowboy coding doing refactoring changes because you have the tests, but this shouldn't be the case. It's very tempting but try to avoid this. Instead, begin writing tests to drive the refactoring in the direction you wish to go. If you notice that an entity has been renamed in the language from Loan to LoanSomething, then start by renaming it in your tests, which will then drive you to rename it in the domain. This is how all refactorings should take place in general, not only in DDD. Choose portions to localize the refactorings, but at the same time to just take little nibbles off the model. Try to cover as much of the domain model as required without making huge refactoring changes. The idea here is to perform small incremented refactorings that increase the cohesiveness of the model while not make huge sweeping changes in the process.

While not the most important or well documented aspect of DDD, Refactoring plays an integral role when performing DDD. It feels slow and sluggish at first, but once you get the hang of it, you can utilize your toolset to aid in the refactoring, such as CodeRush or ReSharper. These greatly speed up the refactoring process in various ways. Don't be afraid or nervous to start refactoring, you will introduce problems but quickly iron them out in the process. Do this often enough, with the correct methods and your domain model will become much more flexible and cohesive for future changes. The domain model is NEVER set in stone. No matter who you are, noone will get it correct the first time. I really want to stress that point. Be comfortable and accept that so you can refactor towards a better model. Do this on an often enough basis and you will drive the domain model to a deeper insight that better reflects what the core idea of the domain model is. Hence, refactoring towards deeper insight.

I hope that clears up anything I may have left out of my presentation and further defines the role of refactoring in DDD. Comments, Questions?

Jacksonville Code Camp

schambers — Sun, 24 Aug 2008 13:56:00 GMT

Jacksonville Code Camp was a great success. Even with faced with changing the venue only 48 hours before the event due to Tropical Storm Fay, Jonathan Bates and the rest of the team was able to pull it off with flying colors! I have great respect for these guys, they did an excellent job.

I will be posting the content on my blog here later this evening, for the time being in case you missed one of my sessions or are in need of some of the sample code I used in the TDD session, you can find the contact on the Google Code Repository here: http://code.google.com/p/jaxcodecamp/

Thank you for everyone that attended. Scott Reynolds had two great presentations on Agile and NDepend as well.

Designing Controllers

schambers — Wed, 25 Jun 2008 02:01:46 GMT

Once you wrap your head around using MVC in your web apps you tend to look at other ways to make your Controllers more descriptive. Specifically the way you structure and document your controllers.

I have noticed that a few portions of MVC design that I can highlight as to where you should pay extra attention and be more discrete in your decisions. These areas are:

Actions
View/PropertyBag variables
Controller/Action reuse

For this posting, I will be using MonoRail in any examples but these ideas are confined to any one MVC framework. You can apply it to your own custom MVC, ASP.NET MVC or anything other MVC framework for that matter.

Actions

Action naming is one area that I think deserves the most attention. There are a couple of different implications of your choices here. You may say, well I can just rename my actions but this drags along some pains because then you have to repoint any hyperlinks you have referring to those actions and refactor any controller code that uses those actions. You can mitigate the hyperlink problem by adding a new Routing Rule to point to the new action, but this should only be used as a temporary fix and shouldn't be a permanent solution.

When naming my actions I always try to limit actions to one word. There are a couple of reasons for this. The less words the easier it is to convey intent of what the action is going to do. This is often hard to convey with one word so sometimes two words are necessary. I try to keep it to one and often cringe when I add that second word. Common action names I have on a controller are, View, List, Search, Find, New, Create so on and so forth. While using jQuery to do ajax calls I am considering prefixing all actions that are called via jQuery with "Ajax". So if I want to perform a Get action that is called via ajax the action name would be AjaxGet, this way it reads like the jQuery methods for performing the calls to a remote page.

Next, I try to steer away from overloading Actions. Sometimes there are exceptions but as a rule of thumb, if I am overloading my actions I take a second look at why I am needing to do this and usually gives me a hint that I need to refactor some code on the controller like break it up into two seperate controllers. This is often the case.

Action names should always be performing that verb on the controller at hand. So for a Controller named UserController, any action should "usually" be working with a User. Some actions do turn out to be utility actions however so use your judgement as to when you can stray away from this idea.

View/PropertyBag variables

When I refer to "View/PropertyBag variables", I am referring to data that is sent to the view from the Controller so we are all on the same page.

On naming of your ProperyBag variables, I always am careful to be consistent with my pluralizing here. If I am sending a collection of objects, be sure to make the variable plural so that you don't mix yourself up. Other than that, I just remain consistent with entity/dto naming in my domain so that it is consistent across the board.

Controller/Action Reuse

This is one area that is a struggle. The easiest and most commonly used approach is Controller inheritance which works without a hitch. In my experience this works well for small scenarios with minimal reuse. Once you get into more complex Actions it becomes cumbersome and undesirable to attempt to apply inheritance to your Controllers. There are a couple of things that can help once you outgrow inheritance.

The first is MonoRails DynamicActions. DynamicActions are a way to create an action in it's own class and then by using attributes, you can hook up the disconnected action to whichever Controllers you wish, passing in parameters that deal with the specific context the DynamicAction is being used in. This works extremely well if the code that needs to be reused is exactly the same except for the objects that it is working with. For instance, list and view actions.

One area where I have found Controller inheritance to work very well is in the area of managing security in your Controllers. What I commonly do is make a "SecureControllerBase" that has an Authentication Filter applied to check if the current user context is authenticated or not, redirecting where appropriate. I commonly use these base controllers for applying filters/monorail attributes across all controllers. That comes in pretty handy.

That concludes my little blurb on Controller design/layout. If you have something to add please add a comment.

Tour of MonoRail Series

schambers — Mon, 23 Jun 2008 01:00:00 GMT

Due to a spell of blogger's block, I thought I would do a series postings to help me get past it. This post begins a series on highlighting various features of the Castle Project MonoRail. All series will be examples from the MonoRail trunk. Some of the features I will be discussing are only available on the trunk (specifically the new Routing Module). To start off the series. The first part will cover MonoRail helpers. The series will have the following topics:

Part 1. Helpers
Part 2. UI Basics (Layouts, Views and Shared Views, View Components)
Part 3. Using the new Routing Module
Part 4. Authentication/Security

Part 5. Dynamic Actions
Part 6. Using JsonReturnBinder for serializing to JSON
Part 7. Creating Wizards using IWizardController

Helpers are classes that are created specifically for providing your view templates with a minimal amount of work to perform or some form of html generation. They should not be used for complex operations or domain logic except for some rare circumstance. They are amazingly simple. A prime example of a helper at work is the FormHelper. This Helper generates various html tags for the purpose of easily using the DataBinder on your controllers. Let's look at the code required to have the FormHelper generate a TextField for us:

   1:  $FormHelper.TextField("blogpost.title")

This will generate the following code when rendered:

   1:  <input type="text" id="blogpost_title" name="blogpost.title" />

What happens here is the FormHelper creates the requested form field and sets the id/name attributes properly so the data can be data bound on the controller action which would look something like this:

   1:  public void CreateBlogPost([DataBind("blogpost")] BlogPost blogpost) {}

As long as you specify the correct id prefix as it appears in your template, MonoRail will do all the binding on the controller. Your controller must also derive from SmartDispatcherController otherwise you will get an exception at runtime. There are many more features that are provided with FormHelper that I will leave you to explore here. There are a number of other helpers available such as AjaxHelper, UrlHelper and DateFormatHelper.

If you want to create your own Helper for whatever task you have at hand all you need to do is create a class and then add an attribute to any controllers that wish to use the helper. The code would look like so:

   1:  public class MyCoolHelper

   2:  {

   3:      public string DoSomethingCool()

   4:      {

   5:          return "cool stuff";

   6:      }

   7:  }

The controller that wishes to use the Helper would look like so:

   1:  [Helper(typeof(MyCoolHelper))]

   2:  public class SomeController

   3:  {

   4:  }

It's as easy as that. This first post is pretty basic. I wanted to start off simple and work up to some of the other topics such as Dynamic Actions and doing Ajax/JSON related data retrieval.

Next time we will go over layouts, views and view components. Should be a fun time!

Refactoring an established Domain Model

schambers — Sun, 22 Jun 2008 12:45:00 GMT

Writing Domain models is by far one of the most difficult things to do. It takes years of practice, errors and learning to get good at writing halfway decent domain models. This becomes even more difficult when we attempt to add ideas like Domain Driven Design to the mix. I am not proposing I am even remotely good at it, but I have had lots of practice.

In the last two weeks my co-worker and I have begun a greenfield project. This project is a complete language re-write due to the fact that the existing technology it is written in, is a dead end. There is no upgrade path and the staff running the software have become more ancy as time has progressed because they knew sooner or later they would have to leave the existing platform behind. The project is greenfield because of no technology constraints, that doesn't mean however there isn't domain language constraints.

The problem with this project is only a handful of people are intimately familiar with the domain. Even then, the few people that were familiar don't agree often on how specific aspects should work. This adds an enormous amount of risk to the project as even though there is a functioning domain model, it is one without a solid foundation and thus weak model.

Enter Domain Model Refactoring...

A few words before I begin. This is an extremely risky thing to do when using Agile/DDD concepts. You run the risk of alienating the client from the domain language. Not only are you going out on a limb here, but you are playing with the business language that the client is using. If I wasn't comfortable with the client enough to talk to them on a real level (my client is within my staff), then I wouldn't attempt to refactor the model for their benefit. Trust is extremely important between the client and developers, as it normally is, but more than usual. Couple that with the fact that in my instance there is no money changing hands, so there is little or no monetary cost involved, that doesn't mean however that there isn't cost in general involved. Cost in this sense is time and effort, not money, although in some instances, time and effort is proportional to money but not in my case.

Usually you are working with a project where you are starting from day one and can work with the client on the domain model. In this instance, they have been using a model for years and I am attempting to change it to make it more effecient for them. Again, proceed with caution.

Step 1. Model the existing Domain

The first step we took is to model out the existing solution with aggregates/entities and value objects. This gives us a good idea of how the model "would" be modeled if it was in a pure DDD type model with all the bells and whistles. This allowed us to reveal holes and gaps in the model (and there was a lot of them). When we approached the client about this, they shrugged and claimed they didn't know why functionality was like it was, just that it was that way. This allowed us to refactor parts of the model that were superfluous and began to make the model more lean.

The existing domain was modeled after the technology it was based on. Because of performance constraints, specific things had to be done in a specific manner in order to salvage performance. After noticing this in the DDD model we created, we refactored the "performance features" into more logical operations with extra documentation. The original application was split into seperate databases that were converged on a daily basis in the morning. Because of this, each database was it's own seperate bubble of transactions/processing. To minimize collisions when everything was merged together, the model was setup in such a way that extra processing was required on the actual users of the system to resolve these conflicts before they happened. We were able to again make the model more lean by removing these constraints as we were refactoring to a single database approach and could remove these constraints.

Step 2. Refactor to a more logical model

Once we had this step complete we could then begin to refactor the model into a more logical manner. This should be done with baby steps and each change be communicated to the client. As long as you have a good idea of what the model should be, then make appropriate changes to the model. All the while documenting what has been refactored into what. You will need to communicate these changes to the client, otherwise you will be the one translating the old model to the new model. This is to be expected at first, but once the client gets running on their own feet they should be able to do this themselves, if they are not then you need to provide more documentation and explanation as to why a particular portion of the model is setup a specific way. In this case, the client didn't actually care what language we changed as long as it still served their purpose and we informed them of any definition changes and provided documentation on why a specific feature was dropped.

Before we laid down a single line of code, we spoke with the client explaining exactly what was happening, why it was happening and then received feedback from them. This part is very important as it will uncover MORE gaps in the model as well as gaps in their understanding of the model. Have someone take notes and address the gaps accordingly in your refactored model. We did this step and realized that some of the changes we made didn't need to be communicated to the client because they already took this for granted, however, we wouldn't have known this unless we spoke with them about it.

Looking back in this project, the key was communication and feedback. If you cut this portion out of the loop you increase risk very quickly. Don't take anything for granted and leave out assumptions. It is better to ask 10 questions and get 9 dumb answers and one good one than to ask no questions at all.

As I said in the beginning of the post, I am no expert on modeling but I have found that this approach has worked well for me and my team. Hopefully you can take something from it.

A call for Alt.Net Speakers

schambers — Sun, 22 Jun 2008 00:08:00 GMT

In an attempt to spread awareness in the North/Central Florida area on Alt.Net topics I am trying to gather speakers familiar with Alt.Net topics to speak at the Jacksonville Code Camp that is coming up on August 23rd. The topics I am envisioning are Domain Driven Design, TDD, BDD, NHibernate, ORM's in general or any other topics that would be of interest in the alt.net space.

If you live in the central/north florida area and are interested in speaking at the code camp please register at http://www.jaxcodecamp.com and please contact me at dkode8 at gmail dot com. This way I can begin to organize an alt.net track at the event when I attend one of the planning meetings.

Hoping to hear from you!

The strive to do better

schambers — Wed, 18 Jun 2008 01:58:00 GMT

Late night thoughts after a coding session before going to sleep.

One skill that I value above all others in software development and life in general is the inner drive and motivation to do better and to do more. It is a skill that can be honed over time. Once you begin to cultivate it, a snowball ensues getting faster and larger as time passes. I am immensely more motivated and driven now than I was a year ago, and the year before that. This is from reading books, writing code, doing presentations at code camps and user groups, getting involved and giving back the community as much as I take out. As well as pushing myself to learn the next step, and the step after that.

For me, it feels almost like a struggle, if I feel myself slowing down or reaching the pinnacle of a particular topic of knowledge, I find another one to begin learning and transition. It's a zone in between comfort and frustration. It's very hard to describe and must be experienced by the inividual doing the exploring. Too much at once causes frustration, not enough precipitates laziness and comfort. There's a balance in between that can be tailored and tuned to.

This applies to all aspects of life, Continuous learning and improvement must always be on your mind. If you stagnate, then you go the way of the dinosaur. Especially in the software industry.

This concept can go from extremes from the macrocosm of your life, all the way to each individual line of code you write. Everytime you look at piece of your own code you should consider that it could possibly be written better at the same time you should be looking at your life and how you can be better to your surrounding environment and fellow beings.

I may be getting a little too zen there however =) Just a thought!

Getting up to speed with the Castle.MonoRail trunk

schambers — Fri, 06 Jun 2008 11:40:00 GMT

Over the last couple of months there have been a slew of great refactorings done on the castle monorail trunk. Some of these refactorings were inspired by ASP.Net MVC changes such as the new routing module. I have just now started to play with monorail trunk so I am by no means an expert on the changes that were done there. If you are interested in getting up to speed as well. The best thing to do is get a fresh copy of the monorail trunk and start looking through the source code specifically on Controller, EngineContext, ControllerContext and IController. After looking at the changes for only an hour or so and updating a project up to the monorail trunk, I can already get a good idea of where things logically should belong now.

General Changes

The controller class has been split up into Controller and ControllerContext. A good deal of Controller "metadata" has been moved to ControllerContext. In addition, an IController interface has been created that is now used within all the Castle services.
RailsEngineContext has been renamed to simply EngineContext.
The ExecuteEnum has been renamed to ExecuteWhen which makes more sense to me.
Certain services have been removed from the Controller
The EngineContextModule has ceased to exist

Routing Functionality

This is the coolest part of the refactorings. Instead of relying on ugly xml configuration for our routes, we can now configure them within our HttpApplication class using the PatternRoute class. This was the hardest portion to find documentation on. There are some postings on the castle project google group that helped me along. You can find the posting here. In addition to reading that, the best way to get familiar with the new routing functionality is to download the trunk and take a look at the Routing tests. They are pretty descriptive and allowed me to wrap my head around them. To outline some of the routing functionality I have an example of a route in one of my applications:

   1: rules.Add(new PatternRoute("/<controller>/<action>")

   2:     .DefaultForAction().Is("index"));

The rules class is an instance of RoutingModuleEx.Engine that you can obtain in your global application. We then pass the Add method a new PatternRoute. This is where we define the route to match.

This route will match anything followed by anything, It will then map anything between <controller>, and pass it along as the controller parameter, and pass along <action> as the action parameter. If no action is passed, a default of "index" will be applied. Specifying a parameter as [something] makes it optional, while <something> is a required parameter. The thing that took me a minute to understand is, when constructing the route, anything you make as a parameter is passed along to the action at hand. This means that if you have a parameter to your action that is someThing, you can place it in your route and that part of the url will be passed along as that parameter. To display this I have another example:

   1: rules.Add(new PatternRoute("/something/<parent>/<param2>/<param3>/")

   2:     .DefaultForController().Is("somecontroller")

   3:     .DefaultForAction().Is("view"));

This route is a little more complex. To get a better idea of how this works, take a look at the associated action signature:

   1: public void View(string parent, string param2, string param3);

As you can see from this example, you can name the parameters to pass along to the action. On that same note, you can specify parameters that aren't included in the url like so:

   1: rules.Add(new PatternRoute("/area/<param1>")

   2:     .DefaultForController().Is("someOthercontroller")

   3:     .DefaultForAction().Is("view")

   4:     .DefaultFor("someOtherParam").Is("someValue"));

In this example we are calling the view action on SomeOtherController that would take a signature as follows:

   1: public void View(string param1, string someOtherParam);

As you can see, the someOtherParam will always have a static value that we define. Not sure if this would be useful to most people but I have already had a use for it when constructing dynamic routes.

One of the more complex parts of the refactorings is definately the routing. There are quite a few posts on them on the Castle Project Users Group and the Development Group so do some searches there if you have more questions about the routes.

That's it for now. Next time we can dive more into the refactorings and changes on the trunk. Feel free to ask any questions!

ReSharper 4.0 Release Candidate available

schambers — Thu, 05 Jun 2008 11:38:00 GMT

FYI, Just read this posting, good news! Resharper 4 Release Candidate is now available. The last time I udpated from the nightly build has been pretty stable. A couple of minor bugs but no biggies.

Good job guys!