BTW Ian is also the guy behind Toji which makes it even more awesome to use Psake.

The idea stuck with me, my wife works for a non-profit after all and I had worked for one recently. I talked to my wife about an idea I had brewing. The place she works for just so happens to be one of the premiere Cancer Retreat facilities in the Northwest (if not the world[but don't tell them]). Where is it that she works you ask, Harmony Hill …. just about the most centering place on earth (ok yeah I know I’m REALLY biased).  Anyway back to the story. I bounced the idea of my cohorts including @NotMyself . Every person I brought the idea to thought it would be amazing. So I decided to move forward with what would become Harmony Hackathon.

Harmony Hill agreed to support the group by providing hospitality services and lodging for the entire group while they were on the hill. I can not even begin to tell you how amazing this staff is, for 48 hrs 12 of the finest developers in the northwest didn’t want for anything!

The setup on my part was pretty easy, invite some of the best programmers in the northwest and ask them to do the one thing they love, code!, for charity…. plus I promised them beer! It worked… attendance was limited by the number of beds we had available for people to sleep in. It was only seconds after sending out the first request did I have people signed up to the eventbrite site.

Finally the day arrived to begin the Hackathon and you could say the excitement in the room was palpable. We started with introductions to the projects (we had initially intended to run to two projects) and to the facilities. We then headed down to the first of several amazing meals on The Hill. After dinner is when the real excitement began. We had decided on building the needed registration/waitlist management tool which is centered around available beds at the retreat center. @darkxanthos took the reigns as PM/customer liaison person and began gathering requirements for the developers to start working with. There was a lot of desire to start coding but also a deep understanding amongst the group that we must first understand the problem before we can solve it. A lot of effort went into making sure we focused on breadth and not rabbit holing ourselves on a single problem. Once again Justin did a great job and with the help of Rodica and Aeden a group of requirements was beginning to emerge as a set of mockups.

We began building out the plumbing and infrastructure of the project and decided on a couple of technology choices… MVC 3 and the default Razor view engine that comes with it.

The next 40 some hours of the weekend were a frenzy of coding…. pulling changes and merging changes…. I swear if nothing else our git skills improved. There were times that a person might have to pull again after merging changes from the last commit only to find out that they were still behind master. It was crazy, as a matter of fact you can see for yourself, thanks to a video from @NotMyself showing the gource animation of what happened.

We didn’t exactly finish, but we did cover some really awesome ground and learn a lot about how to manage such a gathering. A couple of the things we learned are kind of obvious but extremely powerful.

1. While it is exciting to see what can be started from nothing, it is a really good idea to be aware of the problem space to get the best results out of the group. Have a small group meet with the product owner at least once before the event date to flush out stories to keep the team working and not waiting. You can do more the day of the event but you need a foundation to work against.

2. Smaller teams truly do work best. Even a team of 12 is too large optimal is about 5-6. We learned that with all the commits and furious amounts of work we couldn’t help but all get in each others way no matter how much we tried not to.

3. You need a dictator. Sometimes the group can not come to a decision about technology (who’da thought a bunch of Alpha geeks couldn’t agree ) so someone has to be able to make a decision and cast that extra vote. I wouldn’t personally say you need to use this power often, only when the group seems to be wasting time arguing over some tech that doesn’t directly solve the problem. I say this because it is extremely important that the group be open to exploring lots of new spaces so that the benefit is not only to the PO but also to the developers.

4. Infrastructure is important. You really need to have the core infrastructure laid out and decided on before you get started. We chose to use ASP.Net MVC because we are mostly all web developers and are familiar with the technology. We also chose NHibernate and StructureMap as we were all familiar with them as well (well maybe not StructureMap but its concepts are universal … see we learned stuff). This meant there was some setup that was needed to get all the plumbing in place. Had this been ready at a cursory level earlier we would have spent less time shaving that particular Yak.

So the ultimate question remains. Will we do it again? The answer is quite simple, OF COURSE !!! The group learned a lot from the experience and the project continues to move forward. As a matter of fact last night while talking with my wife she informed me that they had already started to talk about how the product could help with other programs at Harmony Hill. We have already started to think about how to plan for the next one and how to get the most out of the event.

The ultimate goal…. start something amazing to help out not only this one organization but potentially help out many others. Start a tradition of greatness and see the program grow. Which is good because we might just need that waitlist manager to help out with the future waitlist for Harmony Hackathon 2012.

A few things have been added like an install dir and the ability to specify a default source as well as override that on a per nuget basis. checkout the readme for more information and examples.

Check out the video from my co-worker Bobby Johnson .

This prompted a few blog posts from the guys here and here.

We kinda came up with the idea that we really needed something along the lines of bundler for ruby gems. So I started with the most simple version possible and Chewie was born. (All credit for the name goes to @NotMyself). At the moment its a basic file and a single line of powershell goodness.

check it out and contribute @ github

Let me first say that many of the projects at work on built on MonoRail which is often considered to be the predecessor to ASP.Net MVC and as such we don’t get a huge amount of exposure to the new toys in ASP.Net MVC immediately.

With that out of the way I was getting prepared to write this post and I just happened to notice that ASP.Net MVC views in .Net 4.0 projects seem to all be of type System.Data.ViewPage<dynamic> , which got me super excited! This makes things even easier!

So here goes a super simple example ….

The Controller :

    public class SampleController : Controller
    {
        public ActionResult Index()
        {
            dynamic viewModel = new ExpandoObject();
            viewModel.Name = "We Named this thing";
            viewModel.SomeInts = new[]{1,2,3};
            viewModel.AMethod = (Func<string>) (() => "This is a sample function implementation");
            return View(viewModel);
        }
    }

The View :

<%@ Page Language="C#" Inherits="System.Web.Mvc.ViewPage" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
<head>
    <title>Index</title>
</head>
<% var viewModel = ViewData.Model; %>
<body>
    <div>
        <span>First Property value : <%= viewModel.Name %></span> <br />
        <span>Second Property value :  <%= viewModel.SomeInts.Length %></span><br />
        <span>A Sample Method Impl : <%= ((Func<string>) viewModel.AMethod)()%></span>
    </div>
</body>
</html>

Crazy huh? yeah I thought so too. This is great news for those times when you need to send some calculated data to the view but you don’t exactly want to run off and build a custom view type.

Ok some NUnit tests this time. Not exactly the best tests, but they should help prove it does work.

The Test :

    [TestFixture]
    public class preseneters_with_dynamic_viewdata
    {
        [Test]
        public void make_sure_you_can_test_them()
        {
            var controller = new SampleController();
            var result = controller.Index() as ViewResult;

            dynamic dynamicModel = result.ViewData.Model;

            Assert.AreEqual("We Named this thing",dynamicModel.Name);
            Assert.AreEqual(3,dynamicModel.SomeInts.Length);
            Assert.AreEqual("This is a sample function implementation",((Func<string>)dynamicModel.AMethod)());
        }
    }

Thanks for reading please leave comments, ideas, corrections, and hate mail in the comments section below.

This series assumes that you are familiar with a few patterns and concepts namely the following:

• Dependancy Injection
• Inversion of Control
• SOLID principals
• MVP
• MVC
• TDD
• Mocks/Stubs

The Problem

One thing that often occurs when using MVP is the tendency to potentially ask your presenter to do too much. I also often see over use of static classes in presenters. As many of you know static classes are hard to Mock thus making other testing scenarios difficult, especially when those static classes access data in a db.  Presenter creation does not usually take advantage of the Container and therefore does not allow us to inject mocks when testing.

A typical instantiation of a presenter would be:

public class SamplePage : ISampleView
{
    public override void OnInit(EventArgs e)
    {
         base.OnInit(e);
         presenter = new SamplePresenter(this);
    }
}

Another thing I often see is that it becomes really easy to allow the presenter to do too much. It is a convenient place to sometimes place a lot of logic that should probably be somewhere else and very discreet. In the below example you can see that our presenter takes on some responsibilities that might be better suited to some external service.

A Solution to statics

I say “a solution” because I am certain there are other options, however we will have a look at the one we are using on my team. The first thing we decided to tackle was the static class problem.

A naive example:

public class SamplePresenter
{
    .....

    public void LoadModels()
    {
        view.Models = ModelBuilder.BuildFor(DateTime.Today);
    }
    .....
}

In this case you can see that ModelBuilder is a static class. It happens to access the datastore and create new entities if they don’t already exist. Internally it loads the ModelRepository from the container via service location and uses it. That is great and all but it makes it hard for me to test other parts of the presenter that may need to mock results from the model builder. The simplest solution, was a simple wrapper class that exposes an interface. It is created via service location as well, for now.

public interface IModelConstructor
{
    IList BuildFor(DateTime a_date);
}
public class ModelConstructor : IModelConstructor
{
    public IList BuildFor(DateTime a_date)
	{
	    return ModelBuilder.BuildFor(a_date);
	}
}

Usage in the presenter is now a little bit more complex… but much easier to mock. As you can see we have a helper IoC class that is static. This gives us access to the container. Sometimes things get worse before they get better.

public class SamplePresenter
{
    public SamplePresenter(ISampleView view)
    {
        this.view = view;
        this.modelConstructor = IoC.Resolve();
    }

    public void LoadModels()
    {
        view.Models = modelConstructor.BuildFor(DateTime.Today);
    }
    .....
}

What this does give us is the ability to use a container that contains mock instances in our tests allowing us to stub methods on them as needed. I use MSpec for most of my testing so the tests below are in that format.

public class with_a_container_of_mocks
{
	Establish context = () =>
	{
	     container = new WindsorContainer();
             IoC.Initialize(container);

	     var modelConstructor = MockRepository.GenerateStub();
	     container.Register(Component.For().Instance(modelContructor));
	};
}

Now we can simply access the mock via service location and provide a stub:

public class when_constructing_models: with_a_container_of_mocks
{
	Establish context = () =>
	{
              .....
              var modelConstructor = IoC.Resolve();
              modelConstructor.Stub(x => x.BuildFor(Arg.Is.Equal(Clock.Today)).Return(someFakeModels);
	};
	......
}

Making presenters do less

This example shows a presenter doing a little more than maybe it should be doing.

public class SamplePresenter
{
    ....
    public void CalculateDistributionFees()
    {
	    //naive example of something that might need to go somewhere else
	    return models.SelectMany(model => model.Account.IsFeeBased)
                              .Sum(account => account.DistributionAmount * account.FeePercentage);
    }
    .....
}

It kinda of feels icky to test the presenter when I want to write tests that ensure the calculation of distribution fees is accurate. With all the overhead of mocking up a view etc it can get really noisy trying to test something very simple. But we simply extract a service (I really am trying not to over use that word) and get it tested. Then make use of it via service location in the presenter. This is similar to the previous technique for handling static classes so I will simply show the service being extracted and its corresponding tests. Gunna use a little NBuilder-foo here to make things pretty.

public class when_calculating_distribution_fees_for_fee_based_accounts
{
    Establish context = () =>
    {
	    some_accounts = Builder.CreateListOfSize(5)
                                              .WhereTheFirst(4)
                                                  .Have(x => x.IsFeeBased = true)
                                                  .And(x => x.DistributionAmount = 100.00m)
                                                  .And(x => x.FeePercentage = .10m)
                                               .AndTheNext(1)
                                                  .Have(x => x.IsFeeBased = false)
                                                  .And(x => x.DistributionAmount = 100.00m)
                                                  .And(x => x.FeePercentage = .10m)
                                               .Build();

        distributionFeeCalc = new DistributionFeeCalculator();
    }

	Because of = () =>
	    fees = distributionFeeCalc.CalculateFees(some_accounts);

	It should_only_add_up_the_fee_based_accounts = () =>
	    fee.ShouldEqual(40m);

	protected static IList some_accounts;
	protected static IDistributionFeeCalculator distributionFeeCalc;
	protected static decimal fees;
}

public interface IDistributionFeeCalculator
{
    decimal CalculateFees(IEnumerable accounts);
}

public class DistributionFeeCalculator
{
	public decimal CalculateFees(IEnumerable accounts)
    {
        return accounts.Where(x => x.IsFeeBased).Sum(account => account.DistributionAmount * account.FeePercentage);
    }
}

Whats next

In the next part(s) of the series I will go more into detail about converting presenters into controllers and refactoring views to be simpler. We will see how service location has become, to quote a friend, our “gateway drug to full blown Dependency Injection”. We will also see our tests become simpler and more controllable.

Thanks for reading this far, hoping that you did indeed get this far, and I hope this has either helped some folks out or at least given people some ideas.

please leave comments, ideas, corrections, and hate mail in the comments section below.

Asking:

How do you organize your tests. Do you separate your unit tests, integration tests and UI tests into separate projects? Do you do anything specific to keep track of your tests? What naming conventions do you use? Do you run them before a check in or is that what the build server is for?
If you are not testing, then how would you like to test your apps if given the opportunity?

This post is my response to the above question.

I tend to have a Specs assembly for each major component of a project, these usually include some form of integration tests using in memory SQLite databases. The first thing most people will think is that I am probably mixing integration tests with my specs/unit tests and getting everything all mishmashed together. That is probably a good observation. As I find myself almost exclusively using MSpec for testing I see no real reason to separate the tests into any other grouping other than by their system components.

An example set of Test assemblies would be :

Monkeys.Core.Specs
Monkeys.Web.Specs

I did learn a few tricks from my friend @cbilson that I really liked and continue to use. That is naming the actual files in the test assemblies about the feature or part of the system we are testing. So for a group of specs that test the calculation of a bunch of distribution dates for a retirement fund based on some frequency (monthly, quarterly, annually etc) the name of the file would be “creating_distribution_dates_for_funds.cs”. This name is also used for the namespace that all the tests live in since MSpec tests are each a separate class. Groups of related tests can be found quickly and helps others that may come on to the project find the tests that describe how something works.

Okay so about those in-memory database integration tests. Well this is another thing that @cbilson and I worked on together (ok mostly him but I helped). Its certainly not a new idea , I got it from some blog post of ayende’s that I read, but it was a major breakthrough in helping us move quickly with testing and be extremely accurate. We were able to not only have nice _FAST_ tests for mappings in nHibernate but also were able to test queries quickly and accurately. Having this ability helps a lot when you want to be able to test with not only the database for your application but also for test versions of other databases you may need to access (most of our apps use at least 3-4 databases). This can make repository testing a no brainer and helps eliminate the kludgy methods people have had to use in the past. @NotMyself, @codereflection and I have even gone so far as to integrate NBuilder into the process for some scenarios making tests clean, expressive and to the point. I’m getting sidetracked I think…. testing is exciting stuff damnit!

Of course all our tests are run on the CI server and we “always” run them all before committing…. right?

I would like to one day soon find a really elegant way to add some more integration testing, maybe even at the UI level, into the process. As this is very painful and hard to maintain today we do our best to test as much as we can. There is no substitution for great comprehensive QA we just hope we make their jobs a lot easier by building well designed rock solid software… that works.

Hope this covers the question and hope someone finds some value in it.

See also my response to the first Developer Blog Banter : My Technology Stack

My publish task looks as such:

   1:  task publish -depends set_prod_configs {

   2:      & $msbuild $web_proj_file /p:WebProjectOutputDir="$publish_dir\" `

   3:                  /p:OutputPath="$publish_dir\bin" `

   4:                  /p:Configuration=$configuration `

   5:                  /p:Debug=false `

   6:                  /t:"ResolveReferences;Compile;_CopyWebApplication"

   7:  }

pretty tame… but after converting this was failing with:

error MSB4064: The “Retries” parameter is not supported by the “Copy” task. Verify the parameter exists on the task, and it is a settable public instance property.
error MSB4063: The “Copy” task could not be initialized with its input parameters.

The solution while obvious took a little while to emerge. This problem seems to occur when continuing to use the .Net 3.5 version of MsBuild. However the proj files are updated to use the .Net 4.0 WebApplication targets.

  <Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" />

So the simple solution to the whole obvious problem… was… use the .Net 4.0 version of MSBuild (Duh!). I had found lots of posts saying to remove some sections of the targets files and other such suggestions. This however seemed fishy to me (plus not feasible on my CI server) which is why I continued looking for a better answer. Once I realized that the targets file had been updated then it became obvious that I was trying to use .net 4.0 build targets with .net 3.5 MsBuild.

Hope this helps someone… and so I don’t make the same mistake twice.

By day I am lucky enough to work with the likes of @NotMyself @codingreflection and other great developers as an Enterprise Developer. Our customers are internal and the corporate preference is for .Net solutions. Our organization and management sees the value in letting developers be productive by allowing them to use the tools that best fit the job. I am proud to work with a team of developers that pushes me to improve myself each and every day.

In my day to day life I am just me, a geek with a passion for learning and all things… well… geeky.

quoting Liam I also favor tools that are :

• are open source. Open source libraries are often designed to facilitate quality practices, not to sell tools. Also, access to the source and the price are bonuses.
• support the software craftsmanship ideology. Small, sharp tools that stay out of the way and don’t force any design decisions.

My work stack:

web framework => MonoRail, ASP.Net MVC 2+
ui => JQuery w/ plugins, Ext JS
viewEngine => Brail, Spark, ASPX
Testing => MbUnit for unit testing, MSpec for BDD … I tend to do mostly just BDD now
TestRunner => TD.Net
Mocking => RhinoMocks. I’ve tried Moq and really don’t like it compared to Rhino
IoC => Windsor
exceptions => Log4net, we are increasing moving towards including Elmah as well
data access => NHibernate + Fluent NHibernate, SqlServer 2000
build => powershell + psake (make in powershell)
CI => TeamCity
version control =>  Git w/ git-svn
misc => NBuilder, SQLite for inmemory testing of repositories and mappings, FluentMigrator, WIX, FileHelpers, A Common lib of tools and useful bits our team has collected over time

My Personal dream stack:

web framework => ASP.Net MVC2+, RoR, Sinatra
ui => JQuery w/ plugins, Ext Js, Coffee Script
viewEngine => spark, haml
testing => MSpec, RSpec , Cucumber
mocking => RhinoMocks, some ruby mocking framework (lol)
version control => Git
build => rake + albacore where needed
IoC => Ninject
exceptions => Elmah, NLog
datastorage => MongoDb ….. pure awesome… on a stick

Alright… have fun!!! ohhh and install IronRuby damnit!