http://github.com/benlovell/webrat-mech/tree/master

With one caveat that this only works for static content as javascript will not be interpreted by mechanize. I will put a selenium based sample up shortly to counter this.

get "/test/?" do
    'in test'
end

The route specified above will match both “/test” and “/test/”.

I have to admit I’ve never performed an upgraded installation of an operating system before as I much prefer starting from scratch. So as you can imagine I was more than curious to see how this would pan out. Especially since the machine is pretty critical to my work — in the .net world at least. Well I’m pleased to say the whole experience went by completely without incident. The process took around one hour in total which included the OS install and the migration of all my applications, settings and the rest of the gumph.

I tend to spend more time in OSX lately since I’ve been working with Ruby a lot more recently but I will say this: Windows 7 is becoming a pleasure to use with each new build. For beta software it is rock solid and the MacBook Pro is very well supported driver-wise. The fact I rely on it daily for work is testament to that. A good acid test for me is seeing which OS I boot into for my day-to-day web browsing, tweeting and like… It almost pains me to admit that this has been Windows 7 more than OSX lately. However despite the wait, we’ll see if the balance is restored when Snow Leopard arrives.

To install I had to:

1. Burn the ISO. I chose the 32 bit edition.
2. Run the boot camp assistant on OSX to partition the drive. I created a 45GB partition for my initial experiments.
3. Reboot the machine with the installation DVD in place.

Pretty simple. After the installation had done it’s thing, Windows started up in a pretty skanky looking desktop. This was cured pretty easily by running the boot camp setup from the OSX installation DVD. This installs the necessary drivers for the iSight, system devices, track pad and your other Mac hardware. A quick reboot and I was back in business and sporting transparent windows and a screen resolution greater than a pocket calculator.

I couldn’t get the Apple wireless keyboard and mouse to pair up over bluetooth but I’m certain a fix for this isn’t too far away.

One small hiccup I did solve was with connecting the 24” LED cinema display. After extending my desktop onto the display I noticed the brightness of the external display was very low compared to the MacBook’s display. This was solved by running the boot camp control panel and altering the brightness from there.

Windows 7 absolutely screams on this machine in boot camp as I expected. I’m still installing Vs2008 and the rest of the .net tools so I’ll report back once I get going.

[sudo] gem install growl-glue

Then add the following lines to your .autotest file:

require 'growl_glue'
GrowlGlue::Autotest.initialize

initialize will accept a block containing a stack of different configuration options. Take a look at what is possible here.

I’m hoping to see a new mac-mini which will supplant the Apple TV I have sitting in my front room. Other notable rumours:

• MacBook Pro 17″ refresh. Should be moving to unibody design, possibly announcements of quad-core.
• Some kind of merger between Apple TV software and the new mac-mini. Hoping for this one.
• LED Cinema Displays replacing the existing cinema displays.
• Larger form-factor iPod Touch like device. Would be ultra-cool but unlikely in my opinion.
• Refreshes across the MacPro and iMac lines. Potentially quad-core in the iMacs.
• Mini DisplayPort added across the board.

Excited yet?

Dilbert

• Working on a couple of small ruby on rails gigs.
• Adding features to my very own top-secret sideline gig (hush hush!)
• Some .net bits with the Castle framework but of course.
• Helping a friend with a hosting startup. Purchasing and configuring various doses of servers, firewalls, switches, DNS, reverse proxies… I’ve certainly learnt a lot the last few months.

Not to mention I have a few interesting happenings coming down the pipeline so do stay tuned!

In our last post we tidied up a few bits and improved our code-base rather than actually adding features as such. This time we’re going to move down into the persistence and start to drive out this notional layer.

We’re going to handle data access using the repository pattern. The repositories will work on our ActiveRecord entities ensuring they’re persisted to our database. We will introduce a new interaction between our service BlogPostService and the newly introduced repository interface IBlogPostRepository. Let’s get on and write a test:

The test above is fairly self-explanatory. We’ve introduced the IBlogPostRepository and we’re passing it into our BlogPostService which should then call the Save method passing our mapped post. We need to get rid of the red code and get the test passing, so first we must create our new interface, and then modify the service constructor:

We need to modify our other tests that construct the BlogPostService as they’re still assuming only a single argument constructor exists. As we have some duplication going on we’ll push this construction up into our setup code:

We should be able to run our tests in this fixture now:

As expected, since our BlogPostService doesn’t actually do much with our repository yet, we need to do some pretty minor tweaking to pass this test:

Let’s try again now:

  Cool, let us try and run the whole suite including our integration type tests:

The integration tests are failing as we’ve yet to map the new dependency in our Windsor configuration. We can specify this now:

We still have failing integration tests though, so we need to add the BlogPostRepository specified in our configuration:

As you can see it doesn’t do much, but we just want our tests passing at this stage. Let’s run the whole suite of tests now:

Great, we have a working product once more. I’m going to finish here, as ever, the latest changes have been committed:

http://code.google.com/p/mr-blogengine/

Next time we’ll make our new repository more useful and finally hit the database!

First step is to build the Castle trunk and update our references to the latest versions. Secondly, we’ll incorporate a few changes suggested by Hammett.

After building and replacing our references with the latest Castle build I’ll run the tests as a sanity check before we proceed:

With that out of the way our first code change will ensure we play nicely with HTTP. It is considered good practice to ensure requests which update or create resources is carried out via POST – so we can modify our only PostController.Save action to ensure this is so but before we do this we’ll write a test:

Running our test produces the following:

We’ll modify our Save action now to ensure we only accept the POST verb:

We have added the AccessibleThrough attribute and explicitly specified that our action must only allow the POST verb. We’ll run our test again and make sure everything is working as expected:

The next step is to modify our add.vm view to use the helper methods to generate our form tags. We’ve done that and once again we’ll run our tests:

I’m noticing a little duplication creeping in to our integration tests that should be removed. Also, until now we’ve had to assume that a web server is running on a specific port on our development machine in order to run the integration tests. Through a little tweaking we can spin-up a temporary server in our test fixture setup code and host our test code there instead.

First we add the WebDev.WebHost.dll to our lib project directory and ensure we’re referencing this from the testing project. The next step is to create an app.config file in the testing project so we can configure where and from which port our testing server should be hosting from:

  Now we add some setup code for the fixture:

We’ll also make sure we bring the server down when we’re finished:

Now ensure the VS web server is not running on the same port, then we can run our tests and make sure our latest changes work out:

Now, since we specify the web root and port through configuration, we should also use these configurable values to determine the URLs in our tests:

You can see our tests now call BuildTestUrl to determine the full URL where we’re hosting the development server. Neat. I’m sure when we add further integration fixtures we’ll extract class this, but for now we have a nice working set of tests and should remember the principle of YAGNI!

I’m going to cut this installment short here. In the next post we’ll get back into the swing of it and continue implementing features.

As ever, the latest code has been checked in and is available here:

http://code.google.com/p/mr-blogengine/

Its interesting contrasting the two approaches not to mention the differences between the ASP.NET MVC framework and Castle Monorail way of getting things done.

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:

1. Make the DTO’s properties virtual so we can mock them. This is in preference to extracting an interface.
2. Implement IBlogPostMapper.
3. 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!

1. Map from the AddPostRequestDto to our actual BlogPost aggregate root.
2. Validate the BlogPost.
3. Persist our new BlogPost.

We need to write another test to flesh out the interaction between our service and something that can map from the DTO to our BlogPost:

We’re now expecting the BlogPostService to accept the mapper in its constructor, and defining an interaction between the service and the mapper. Before we can get this to compile we need to make a few more changes to our test fixture:

We’ve modified an existing test to allow for our new dependency and performed some setup tasks. We’ve introduced the IBlogPostMapper and IBlogPost interfaces by way of our test. Running the test causes the compiler to choke so lets go ahead and implement what we need to pass the tests:

Lets go ahead and run our BlogPostServiceFixture tests:

Righteo, that went well. For the sake of completeness lets run our full test suite:

The integration test is failing as we’ve yet to wire up the BlogPostService dependencies in the container. Before we can do this we need to drive out the interfaces we’ve introduced. We’ll do that in the next post.

In the last instalment we finished up with a suite of passing tests. However, we’ve yet to produce anything remotely usable so lets continue by reaching down further and driving out our services/persistence. We’ll start by writing the following test:

We’ve meddled with our test setup a little to introduce the MockRepository for mocking out our PostController’s new dependency on the IBlogPostService. Our test now calls the AddPost method on our service interface and sets up the resulting AddPostResponseDto. Running the test produces a bunch of compiler whinging so we best implement the newly introduced bits:

These are the only changes and additions we’ve made in order for the tests to compile and run. Running our test now produces the following result:

As we’ve yet to modify the PostController.Save(…) call to include a call the newly introduced IBlogPostService dependency. Lets go ahead and do this now:

We’ve now included the call to our newly introduced service and we set the responseMessage if the response is signaled as successful. Lets run our test now:

It works, ship it! Actually no, again we’re pretty low on actual functionality right now. Remember we’ve yet to actually drive out any implementation of the IBlogPostService interface as yet and I expect that the acceptance test will fail horribly since we didn’t wire up the necessary container configuration either. Lets go ahead and run the whole test suite and see what gives:

In the brief moments the browser appears during the test we can see the following:

Hmm, as I predicted earlier our application fails to run due to the lack of proper container configuration. Before we can do this we need to implement the IBlogPostService interface somewhere. We need to write a failing test to begin our foray into the implementation of a BlogPostService:

Lets create the BlogPostService only performing the steps necessary to pass the test above:

Run the test:

Now we have a working BlogPostService we can now wire up our container configuration to pass the acceptance test:

Now running the full suite of tests produces the following:

Our tests pass!

That’s it for this post. I’ve checked in the latest changes to the repository. In the next post we’ll continue our efforts and begin to implement validation on our screen-bound DTO’s.

Google code hosted project: http://code.google.com/p/mr-blogengine/