Archive

Archive for July, 2008

Using Rhino Mocks with Void (or ‘Sub’) Methods

July 22nd, 2008 Scott Lilly Comments off

I ran into a bit of trouble the other day when I was writing a test with Rhino Mocks.  It took a while to find the solution, so I figured I’d post it here for anyone else looking to do the same thing.

The problem I had was trying use a mock object for my data access layer, and calling a void method on the class.  There are thousands of examples of how to mock a method call that returns a value, but it took a while to find out how to handle a method call that doesn’t return anything.  In my test below, if the method returned something, I’d use code like this:

using ( mockery.Record() )
{
   Expect.Call( dal.ExecuteQuery( null ) ).IgnoreArguments().Return( results );
}

For a void method (or ‘Sub’, instead of ‘Function’, for the VB.Net developers), you need to set up a delegate instead. See the line that calls “ExecuteNonQuery” for an example.

[Test]
public void CreateNewUserStory()
{
   MockRepository mockery = new MockRepository();
   IDataAccessor dal = mockery.CreateMock<idataaccessor>();

   IUserStoryControl screen = mockery.Stub<iuserstorycontrol>();
   UserStoryController controller = new UserStoryController( dal );

   screen.StoryTitle = “Test title”;
   screen.Description = “Test description”;

   using ( mockery.Record() )
   {
      Expect.Call( delegate { dal.ExecuteNonQuery( null ); } ).IgnoreArguments();
   }

   using ( mockery.Playback() )
   {
      controller.CreateNewUserStory( screen );
   }

   Assert.AreEqual( “”, screen.StoryTitle );
   Assert.AreEqual( “”, screen.Description );
}

Categories: Agile, Development, Mock Objects, Testing Tags:

Putting interfaces in their own project(s)

July 13th, 2008 Scott Lilly Comments off

When I started using test-driven development and the model-view-controller pattern, I noticed a change in the way I broke up the projects in a typical solution.  Well, I noticed several changes, but the one I’m going to talk about now is how the user stories started to become the API of my business logic.  Because of the separation of the UI and the business logic that’s created by using the MVC pattern, my user interface has become a consumer of my business logic through this API.  Writing code this way gives me the flexibility to use the same logic with a completely different UI.

That may not sound like the kind of things that comes in handy very often; however, it’s making my life much easier for the latest project I’m working on.  I’m working on an ASP.Net website, but I also plan on creating a Visual Studio plug-in, so developers can access the website features without needing to leave their editor and open a new browser.  I may also end up writing a system tray tool that works the same way.  I haven’t decided if the plug-in will communicate with my application by a web service, remoting, or WCF.  But whatever method it uses, I’ll just end up writing a small bit of wrapper code in it to communicate with my business logic through the user story API.

Normally, my solution file will start out with four projects in it.  They are:

- MyLibrary (containing things like my data access layer)
- Domain (the application’s business logic)
- Application (the UI project)
- TestDomain (unit tests for the Domain project)

The MyLibrary and Domain projects each contain an Interfaces folder, and the files within them are in the MyLibrary.Interfaces and Domain.Interfaces namespaces.  The Application project has references to both the MyLibrary and Domain projects.  However, since I’m going to have additional projects that will be passing objects of the interface types into a web service (for this example), They will either need to include the complete MyLibrary and Domain assemblies, or I’ll need to move the interfaces into their own assemblies.  In order to keep the installations for the new projects small, I’ll move the interfaces into their own projects.  So, the solution will now look something like this:

- MyLibrary (containing things like my data access layer)
- MyLibrary.Interfaces (the public interfaces used within MyLibrary)
- Domain (the application’s business logic)
- Domain.Interfaces (the public interfaces used within Domain)
- Application (the UI project)
- Notifier (system tray notifier project)
- Plugin (Visual studio plugin project)
- WebService (used by the Notifier and Plugin projects to communicate with the Domain layer)
- TestDomain (unit tests for the Domain project)

The Application and TestDomain projects (along with the new Notifier and WebService projects) will now need references to the new *.Interfaces projects.  However, the Notifier and Plugin will only need to have the small *.Interfaces assemblies included for the installation.

Categories: Development Tags:

Building my ultimate development computer (Part 3, Software)

July 9th, 2008 Scott Lilly Comments off

Now that I have a clean development environment running as a virtual machine, it’s time to set up the software I need to do my work.

The first thing I did to my development virtual machine was to set the desktop background to a different color.  Since I’ll be switching between multiple VMs, I figured I’d add a visual indicator as to what machine I’m currently on.  Obviously, the background won’t be visible when I have my programs open.  If I still need something to remind me what machine I’m on, I’ll use one of those utilities that keeps the machine name and details floating above all applications.

For web browsing, I downloaded an installed the following:
Firefox
Opera
AdBlock
Avast! anti-virus (I had been using AVG, but it’s been having some problems lately.  See here and here for more
details)
AdAware

For .Net development, I installed the following:
IIS (Map a virtual CD drive to the operating system ISO, to get the required files)
SQL Server 2005
Visual Studio 2008
Silverlight

Then, the development libraries and tools that I use on a regular basis:
RhinoMocks
NUnit
TestDriven.Net
ReSharper 4.0 is next on my list

For source control, I went with Visual SourceSafe.  I prefer to use Subversion when developing with others; however, VSS suited all the extremely basic requirements I need for solo development.  Plus, it integrates better with Visual Studio than Subversion does.  When I tried VisualSVN and AnkhSVN, there were still a few things they had trouble with (moving and renaming files, IIRC).

For my continuous integration build server, I went with TeamCity, since it makes builds so much easier to create and manage than CruiseControl.  Ideally, I’d set this up on another VM, but I’m keeping things simple, until I find a need to make them more complex.  Something I’ve seen with their system tray notification tool is that the web server service hasn’t started before the system tray notification tool tries to connect to it.  I get a pop-up that the build website is not available yet.  I just give it a minute for the website to start up, then tell it to retry connecting.  I sent off an enhancement suggestion to the TeamCity developers that it would be nice to have a configurable wait setting before the notifier tries to connect to the web page.
TeamCity

Although it’s not on my development VM, I want to mention that I also installed SpamBayes on my ‘office’ VM.  This is a nice filtering tool that helps keep spam out of my inbox.
SpamBayes

Categories: Development Tags: