Development Blog

 Saturday, September 29, 2007

First some code:

UserEntity user = New.User("bob").In(New.Company("ACME")).With(
  New.PurchaseOf("ProductA")
    .WithAcademicSlot(1).FilledBy(New.EnrollmentIn(101).ThatIsCanceled)
    .WithPlacementSlot(1).FilledBy(New.EnrollmentIn(1)));

This code actually creates and saves (with NHibernate) about 12 or so entities. We can use code like this to set up one off sample data for tests in a way that's easy to read, understand and change. There is a decent amount of magic that goes into making this work and I wanted to talk about how I did it.

First we have a FixtureContext, which is just a hub for the DaoFactory, the current Session, and three helper classes, New, Current and Existing. New is the class responsible for the beginning of the syntax you see above. Each method on New returns a Creator. There's some magic in Creator, so here's the code:

public class Creator<T> : FixtureContextAware where T: class, new()
{
  private T _creation;
  
  protected T Creation
  {
    get { return _creation; }
    private set 
    {
      if (Current.Get<T>() != value)
      {
        Current.Push(value);
      }
      _creation = value; 
    }
  }

  public Creator(IFixtureContext context) : base(context)
  {
    Creation = new T();
  }

  public Creator(IFixtureContext context, T creation) : base(context)
  {
    Creation = creation;
  }

  public static implicit operator T(Creator<T> creator)
  {
    if (creator._creation == null) throw new Exception(
      String.Format("Creation of {0} is null, it probably shouldn't be.", typeof(T)));
    creator.Current.Pop<T>();
    return creator._creation;
  }
}

The first thing is that Creator is a subclass of FixtureContextAware, which is just a helper base class that provides access to FixtureContext's children. Next there are a few references to Current which is simply a collection of stacks of entities so that Creators can refer to other entities that are being created so they don't have to be passed around. This is better explained with an example. In the beginning example you see New.EnrollmentIn(101). An enrollment requires a User to be created, so because there is a User in this creation context, we can do this:

public CourseEnrollmentCreator(IFixtureContext context, short number) : base(context)
{
  Creation.User = Current.User;
  Creation.Course = Existing.Course(number);
  Creation.StartDate = DateTime.Now;
  Creation.EndDate = DateTime.Now.AddMonths(1);

  Session.Save(Creation);
}

The next thing is that the creation itself is stored as Creation in the Creator. This can either be new'd up or can be passed in to the constructor.

The coolest part (at least in my opinion) is the implicit operator. This allows you do to do things like: UserEntity user = New.User().Foo(), where each of those methods returns a UserCreator, but at the end of all of it the Creator is implicitly cast to a UserEntity, the thing actually being created. This also serves as an excellent time to pop the entity from the Current stack.

Next we have the Existing class. This is essentially just a wrapper for your Daos/Repositories so you can fetch things that are already in your database (like Existing.Course(number) or Existing.User("bob")).

With this simple framework in place, the next step is to start writing your domain specific Creators. Here's an example:

public class PurchaseCreator : Creator<PurchasedProductEntity>
{
  protected PurchaseCreator(IFixtureContext context, PurchasedProductEntity creation) : base(context, creation)
  {
  }

  public PurchaseCreator(IFixtureContext context, string productName) : base(context)
  {
    Creation.Product = New.Product(productName);
    // Initialize Purchase...
  }

  public PurchaseCreatorWithSlot WithAcademicSlot(int credits)
  {
    // Create and add slot...
   
    return new PurchaseCreatorWithSlot(Context, this, slot);
  }

  public PurchaseCreatorWithSlot WithPlacementSlot(int credits)
  {
    // Create and add slot...

    return new PurchaseCreatorWithSlot(Context, this, slot);
  }

  public PurchaseCreator WithSessions(int credits)
  {
    // Create and add sessions...

    return this;
  }
}

public class PurchaseCreatorWithSlot : PurchaseCreator
{
  private readonly PurchasedCourseEnrollmentSlotEntity _slot;

  public PurchaseCreatorWithSlot(IFixtureContext context, PurchasedProductEntity creation, PurchasedCourseEnrollmentSlotEntity slot) : base(context, creation)
  {
    _slot = slot;
  }

  public PurchaseCreatorWithSlot FilledBy(CourseEnrollmentEntity enrollment)
  {
    // Fill slot...
  }
}

Then we add a PurchaseOf(string productName) method to New that will create and return a new PurchaseCreator. We can also add a PurchaseOf(ProductEntity product) and pass a New.Product("Product") in instead. You can make it as granular or magic as you want. Also, Notice that WithAcademicSlot and WithPlacementSlot return a subclass of PurchaseCreator that adds another method. Using techniques like this you can make some very verbose and context sensitive fixtures.

We also make our HibernateTests base class FixtureContextAware so that we can use nice syntax in our tests.

Here is the source for the basic framework. Let me know what you think. 

by Aaron on Saturday, September 29, 2007 3:48:54 PM (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [1]  |  Trackback
 Monday, July 30, 2007

Writing ReSharper.TestDrive was kind of an exercise in tiny classes for me. I didn't TDD the whole thing because so much of it was just experimenting with ReSharper's mostly undocumented API and EnvDTE, though I did TDD a good portion of it after my initial spike. After I got a working prototype implemented I spent a lot of time refactoring it into tiny classes that for the most part follow the Single responsibility principle.

As this is the most code I've ever thrown out into the public at any one time and it was a bit of an experiment for me, I wanted to take this chance to ask the community to review my code. If you have the time, feel free to look over the code and tell me what you think. Likes/dislikes/hates/loves anything is fair game--feel free to rip on it. Maybe we'll get some interesting discussion out of it.

Source

by Aaron on Monday, July 30, 2007 9:54:52 AM (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [2]  |  Trackback

Note: You must have ReSharper 3.0.1 in order for this to work.

When you're doing TDD you'll create two classes every time you need one. You'll create one for the class itself and you'll create one for the tests for that class. ReSharper makes it a little bit easier by allowing you to write your tests and then alt+enter on your class under test to create it. Unfortunately it will create the class in your test project and not your project under test. It may actually create it in that same file (I don't remember) which means you have to Move to File. Then you have to drag it over to the project under test and/or change the namespace. Pretty obnoxious for something we have to do so often.

So... I decided to write a ReSharper plugin to do just that. It'll also create tests from a class under test (just in case you cheated and created your class first). Heck, it'll even create all the folders you need to.

This current version makes a few assumptions about your structure and it's not configurable at all unless you actually hit the code. Here are the assumptions it makes:

  • The tests for Project.Foo live in Project.Foo.Tests.
  • Test classes have the "Tests" suffix.
  • Test classes live in the same namespace as the classes under test.
  • The tests for ClassFoo are in ClassFooTests.

I lied when I said it wasn't configurable at all. After you've used it for the first time it will have created ReSharper file templates that you can edit to customize what is generated when you create a test or a class under test. Just go to ReSharper>Options>Templates>FileTemplates>User Templates>TestDrive.

To install it just extract it somewhere and run install.cmd, or just copy the dll to your %APPDATA%\JetBrains\ReSharper\v3.0\vs8.0\Plugins\Resharper.TestDrive (obviously you'll need ReSharper installed).

To use it, just have the cursor somewhere within a class that doesn't have a test, or a test that doesn't have a class under test and hit Alt+Enter, select Create X Tests... or create X... and hit enter. In order for the light bulb/alt+enter to show up it will need to be able to find an associated project to the one you're in (Sample.Project.Tests<->Sample.Project).

I've got more plans for this but I wanted to get it out there to see what you all thought. Oh, and in case you're wondering, Bunker is just a really light nearly feature-free IoC container that Jacob wrote in a day for another project we're working on.

Binaries
Source

by Aaron on Monday, July 30, 2007 9:14:15 AM (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [1]  |  Trackback
 Friday, June 01, 2007

OK, let me start out by saying that I'm hardly an expert on the subject of ORMs. I've only really used NHibernate, and I've still got plenty to learn about it. That said, I do know a bit about being lazy...

When working in any real application you quickly realize that actually exercising lazy loading is something that should probably be avoided at all costs. You want to fetch everything you need to handle a request in one go. Scott Bellware recently struggled with this issue as we all have, and the general consensus in the comments is that you should load what you need and not lazy load anything (unless of course that lazy load happens in a branch less often traveled). Udi Dahan provided a link to a rather elegant solution to the problem that I think I'm definitely going to explore.

Even with Udi's solution, you're still required to keep the fetching strategy in sync with the domain. This isn't an incredibly difficult thing to do, but it requires discipline and effort. I've been thinking for a while about this and a few other possible performance tweaks that can make ORMs easier to use and even a bit quicker than they are today.

Let's talk about another performance issue briefly. Say you want to Display an email list containing all of your users. The list should display just their username and email address, nothing more. The easy way to do fetch the data would be to do a "from UserEntity". But is that the most efficient? What if UserEntity has 10 fields? 20? 30? Is it worth explicitly querying for "u.Username u.Email from UserEntity u"? Let's find out. Being lazy, I simply borrowed James Avery's Northwind NHibernate example, ported it to NHibernate 1.2 and added a new mapping and class called TrimmedOrder. The class is exactly the same, but the mapping only contains the Freight and ShipName properties. I also commented out the many-to-ones in both Order and TrimmedOrder. You can get the source here.

The rest was just a few simple tests. One for reading, and one for writing. Here are the results:

  Order TrimmedOrder Performance Gain
Read Test 18.62 ms 11.66 ms 1.6 times faster
Write Test 227.13 ms 161.24 ms 1.41 times faster

Notes: The Read Test was averaged over 50 iterations and the Write test was averaged over 20 iterations. The db was queried for all orders once before anything was tested because I found the first query was always slower, but after that all queries seemed level. In the writing test, I wrote random values to the two properties mapped by TrimmedOrder. The Write Test values were adjusted by subtracting the read test values so that only the write itself was timed (in theory). 

Now, these gains aren't anything to write home about, but they are significant. Some of you may wonder why the Write Test sees any gain given that the database calls would be exactly the same, as NHibernate doesn't update columns that didn't change. Well, without profiling, I'm willing to bet that the reason is simply that NHibernate has discover which fields changed while flushing by testing them against their old values.

So now we have two problems: we have to know exactly what collections the domain needs ahead of time or we lazy load and unless we use projection queries, we're not getting the best performance we can get. Also, NHibernate doesn't currently support deferred (lazy) property loading, so projection queries return object[]'s rather than partially initialized entities, which means that as far as I know, you cannot use projection queries to do updates, so we just can't solve the Write problem without additional mappings or something else hackish.

What do we do? Yes, I'm finally nearing the point of this post. What if we taught the ORM to learn? Bear with me here. Let's go back to the email list example. If we were using Udi's Fetching Strategy approach, we'd do something like this:

IList<UserEntity> users = Repository<IEmailListService>.FindAll();

Which would ultimately get a FetchingStrategy associated with this service. Now what if every object fetched by this FetchingStrategy was proxied and would communicate back to the FetchingStrategy about its usages... and the FetchingStrategy remembered how its objects were used, so the next time it got invoked it would only return what was used last time... and it would keep learning, and refining so that it would simply return all the fields and collections that were ever accessed via that particular FetchingStrategy. If ever it returned too little, it would just lazy load what needed to be loaded and make note that it should provide that field next time (of course this would be configurable so that it would just load everything on a miss so you're not hitting the db several times in these cases). This would mean the first time your FetchingStrategy was invoked it would be "slower" but most every time after that it will have adapted and improved... all for mostly free. And yes, I know that Udi's FetchingStrategy would just return an hql query and live closer to the domain objects, but mine would live closer to NHibernate and it would probably be responsible for actually querying from NHibernate (so it's probably really a Dao, but you get my point.)

There are probably a few other things this could help with too, such as marking queries as readonly automatically so as to avoid an unnecessary and costly flush (unfortunately this is not currently supported any ways).

Caveats? Plenty I'm sure. Here's some I can think of:

  • There's the fact that it's not implemented. Jacob and I started to work on it and quickly decided it would be best to get lazy loaded properties hashed out first. It's probably a decent ways off the NHibernate radar, but maybe we can change that.
  • Then there's the proxy element. The Entities are often proxied normally to lazy load collections and such, so I don't think adding in reporting back to the FetchingStrategy would be a huge burden.
  • Complexity... yeah, this is complicated, but so are ORMs and software :)
  • Increased startup cost (kind of). You could always persist the strategies to help alleviate this a little...
  • Instance variables, access strategies, etc. Much like lazy loaded collections, restrictions would apply to lazy loaded properties and such. You'd probably need to just always load things that are field accessed, and you'd certainly have to avoid accessing the instance variables that back deferred properties.
  • Objects fetched by multiple strategies. This is a big one. There will be tons of questions when it comes time to solve this problem. If I access property A after an object is fetched from two different strategies, do I notify both strategies? Will data be fetched twice if both strategies need it?
  • Caching complications. Most of these would come from the lazy loaded properties, so that's something that'd have to be tackled eventually.

Now I'm just waiting for Gavin King or Sergey Koshcheyev to come tell me why this is a horrible idea, but until then, what do you all think?

by Aaron on Friday, June 01, 2007 9:12:39 AM (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [5]  |  Trackback
 Wednesday, April 11, 2007

We were on the phone today with Scott Bellware and he asked us if we could toss together a simple MonoRail project that showed the Castle.Tools.CodeGenerator stuff in action. A few other people have been asking us to do something similar for the other things we've been discussing on our blog. So, Aaron and I sat down and pair-programmed out some source that does just that. It shows several things:

  • An Action/View map is generated using Castle.Tools.CodeGenerator, and used to do view renderings, and (if desired) action redirections and the like.
  • PropertyBag wrappers are created using the IDictionaryAdapterFactory code that Lee contributed.
  • We show how we test our controllers using the test fixture code Aaron has been posting about.
  • It has a small service layer that roughly shows how we architecture our code around here.
  • It uses Windsor integration, so you can see how that's used if you've been curious.

Please keep in mind this took us about an hour to whip up and we did not actually practice full TDD with it. Enjoy!

Source

by Jacob on Wednesday, April 11, 2007 5:41:13 PM (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [13]  |  Trackback
 Monday, April 09, 2007

We use a ton of Visual Studio plugins. CodeRush is one of them. Its templates are awesome, and its got a few nice refactorings that Resharper doesn't have. They're a little tricky to get working together, but not impossible. One thing I use a ton is GotoType under Resharper. One thing I find myself doing all the time is going between a class and it's fixture. Because I couldn't see anything else that would do it, I tossed together a CodeRush plugin for that very thing.

You just bind a key (I use Ctrl+Shift+X) to Eleutian Goto Fixture. All it does is do a regular expression search through type names in your solution. Say you're on HomeController. Because the class name doesn't end in "Tests" it will look for one that ends with "HomeControllerTests". If the class were HomeControllerTests, it would strip the suffix off and look for a class with a name that ends with "HomeController". It's missing a few things I still want. For example, for multiple matches I would like a menu, or the ability to cycle through them a la tab completion. I'm not sure of the best way to do the menu and haven't decided if I'll just do the cycling. If there's interest I'll think more about it.

There are a few optimizations, the first is that it will only look in projects ending with ".Tests" when looking for the test fixture. Also, it will keep a rolling queue of the last 10 types you jumped from and check those first. Both are handy when you have 40 projects and tons of classes. I started off with other loftier goals for the plugin, which might explain why there's so much other code.

In order to install this thing drop the binaries into your C:\Program Files\Developer Express Inc\DXCore for Visual Studio .NET\2.0\Bin\Plugins directory. Start Visual Studio and choose DevExpress | Options and then find the Shortcuts tab. In there, you can add a new shortcut (there's an icon in the lop left) and bind the keystroke you desire to the Eleutian Goto Fixture command.

It's my first CR plugin, so forgive me.

Source and Binaries

by Jacob on Monday, April 09, 2007 10:29:41 AM (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [1]  |  Trackback
 Wednesday, March 28, 2007

Shortly after I posted my original EleutianControllerTests, Scott Bellware, Hamilton and myself chatted about the subject, and Hamilton decided to help out by making some of the previously internal methods public. Context still isn't settable directly however (maybe we should have him change that too...), so you still have to do a little bit of magic to get your context in there. There's actually more code to do this now then when I just set it w/ reflection, but it's arguably more "correct" and doesn't involve "reflection" and you can mock more (like logging and such). Anyways, here's the code:

 

using System;
using System.Collections;
using System.Collections.Specialized;
using System.IO;
using System.ComponentModel.Design;
using System.Security.Principal;
using System.Web;

using Castle.MonoRail.Framework;
using Castle.MonoRail.Framework.Internal;
using Castle.Core.Logging;
using Castle.MonoRail.Framework.Services;

using NUnit.Framework;

using Rhino.Mocks;

public class EleutianControllerTests
{
  #region Constants
  private const string ApplicationPhysicalPath = "Q:\\PhysicalPath";
  #endregion

  #region Member Data
  protected string _virtualDirectory = String.Empty;
  protected MockRepository _mocks;
  protected IRailsEngineContext _context;
  protected IRequest _request;
  protected IResponse _response;
  protected IServerUtility _serverUtility;
  protected IDictionary _session;
  protected Flash _flash;
  protected IViewEngineManager _viewEngineManager;
  protected ControllerMetaDescriptor _descriptor;
  protected NameValueCollection _parameters;
  #endregion

  #region Test Setup and Teardown Methods
  [SetUp]
  public virtual void Setup()
  {
    _mocks = new MockRepository();
    _viewEngineManager = _mocks.CreateMock<IViewEngineManager>();
    _descriptor = _mocks.CreateMock<ControllerMetaDescriptor>();
    _context = _mocks.CreateMock<MockRailsEngineContext>(_viewEngineManager, _descriptor);
    _request = _mocks.DynamicMock<IRequest>();
    _response = _mocks.DynamicMock<IResponse>();
    _serverUtility = _mocks.DynamicMock<IServerUtility>();
    _session = _mocks.DynamicMock<IDictionary>();
    _flash = new Flash();
    _parameters = new NameValueCollection();
  }

  protected void InitializeController(Controller controller, string areaName, string controllerName, string actionName)
  {
    controller.InitializeControllerState(areaName, controllerName, actionName);
    controller.InitializeFieldsFromServiceProvider(_context);

    InitializeRailsContext(areaName, controllerName, actionName);
  }

  protected void InitializeRailsContext(string areaName, string controllerName, string actionName)
  {
    SetupResult.For(_context.UrlInfo).Return(
      new UrlInfo("eleutian.com", "www", _virtualDirectory, "http", 80,
                  Path.Combine(Path.Combine(areaName, controllerName), actionName), areaName, controllerName,
                  actionName, "rails"));
    SetupResult.For(_context.Server).Return(_serverUtility);
    SetupResult.For(_context.Flash).Return(_flash);
    SetupResult.For(_context.ApplicationPath).Return("/");
    SetupResult.For(_context.Request).Return(_request);
    SetupResult.For(_context.Response).Return(_response);
    SetupResult.For(_context.ApplicationPhysicalPath).Return(ApplicationPhysicalPath);
    SetupResult.For(_request.Params).Return(_parameters);
    SetupResult.For(_context.Session).Return(_session);
  }
  #endregion
}

public abstract class MockRailsEngineContext : IRailsEngineContext
{
  #region Member Data
  private IViewEngineManager _viewEngineManager;
  private IControllerDescriptorProvider _controllerDescriptorProvider;
  #endregion

  #region Properties
  public abstract void Transfer(string path, bool preserveForm);
  public abstract string RequestType { get; }
  public abstract string Url { get; }
  public abstract string UrlReferrer { get; }
  public abstract HttpContext UnderlyingContext { get; }
  public abstract NameValueCollection Params { get; }
  public abstract IDictionary Session { get; }
  public abstract IRequest Request { get; }
  public abstract IResponse Response { get; }
  public abstract ITrace Trace { get; }
  public abstract ICacheProvider Cache { get; }
  public abstract Flash Flash { get; }
  public abstract IPrincipal CurrentUser { get; set; }
  public abstract Exception LastException { get; set; }
  public abstract string ApplicationPath { get; }
  public abstract string ApplicationPhysicalPath { get; }
  public abstract UrlInfo UrlInfo { get; }
  public abstract IServerUtility Server { get; }
  public abstract IDictionary Items { get; }
  public abstract Controller CurrentController { get; set; }
  #endregion


  #region Constructors
  public MockRailsEngineContext(IViewEngineManager viewEngineManager, ControllerMetaDescriptor descriptor)
  {
    _viewEngineManager = viewEngineManager;
    _controllerDescriptorProvider = new ControllerDescriptorProviderStub(descriptor);
  }
  #endregion

  #region Methods
  public abstract void AddService(Type serviceType, object serviceInstance);
  public abstract void AddService(Type serviceType, object serviceInstance, bool promote);
  public abstract void AddService(Type serviceType, ServiceCreatorCallback callback);
  public abstract void AddService(Type serviceType, ServiceCreatorCallback callback, bool promote);
  public abstract void RemoveService(Type serviceType);
  public abstract void RemoveService(Type serviceType, bool promote);
  public object GetService(Type serviceType)
  {
    if (typeof(IViewEngineManager).Equals(serviceType))
    {
      return _viewEngineManager;
    }
    else if (typeof(IControllerDescriptorProvider).Equals(serviceType))
    {
      return _controllerDescriptorProvider;
    }
    else if (typeof(ILoggerFactory).Equals(serviceType))
    {
      return null;
    }
    else if (typeof(IUrlBuilder).Equals(serviceType))
    {
      return new DefaultUrlBuilder();
    }

    return null;
  }
  #endregion

  #region Classes
  private class ControllerDescriptorProviderStub : IControllerDescriptorProvider
  {
    private ControllerMetaDescriptor _descriptor;

    public ControllerDescriptorProviderStub(ControllerMetaDescriptor descriptor)
    {
      _descriptor = descriptor;
    }

    public ControllerMetaDescriptor BuildDescriptor(Controller controller)
    {
      return _descriptor;
    }

    public ControllerMetaDescriptor BuildDescriptor(Type controllerType)
    {
      return _descriptor;
    }

    public void Service(IServiceProvider provider)
    {
    }
  }
  #endregion
}

Source
by Aaron on Wednesday, March 28, 2007 2:51:30 PM (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [6]  |  Trackback
 Tuesday, March 27, 2007

Update: Hamilton committed my patch, so if you're running off trunk you won't need to do this anymore. Thanks Hamilton!

Currently MonoRail uses ResourceSets wrapped up in an implementation of IResource to provide Resources to views. Unfortunately, ResourceSets do not cascade when it comes to resource resolution.  ResourceManager.GetResourceSet does have a flag called tryParents, but all that does is try less and less specific cultures until it finds a match. In other words, if you have two resource files:
Foo.ko.resx: defines A, B
Foo.resx: defines A, B, C

If you locale is ko-KR, calling RseourceManager.GetResourceSet will yield a ResourceSet that maps to Foo.ko.resx, so asking for B will work, but asking for C will not. A ResourceSet only knows about itself.

ResourceManagers on the other hand, are perfectly capable of handling this cascade, which is quite necessary in at least our localized app, as we do not want to have to define strings in all languages for everything. So with ResourceManagers, asking for A, B, and C all behave as expected, preferring the most specified culture and cascading down as necessary.

Below is an implementation of an IResourceFactory that spits out wrapped ResourceManagers instead of ResourceSets.

To use it you'll need to add this to your web.config:

<monorail>
  <services>
    <service id="ResourceFactory" type="Eleutian.Shared.MonoRail.ResourceManagerFactory, Eleutian.Shared" />
  </services>
</monorail>

Source

by Aaron on Tuesday, March 27, 2007 4:13:12 AM (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [0]  |  Trackback
 Thursday, March 01, 2007

I needed the ability to execute a task from an MsBuild project and have MsBuild keep going and not wait around on the process to exit. I was hoping to find an option on the Exec task for this but that search turned up nothing. After scowering a bit I couldn't find one somebody else wrote, so here we go:

using System;
using System.Collections;
using System.Collections.Specialized;
using System.Diagnostics;

using Microsoft.Build.Tasks;

namespace AsyncExec
{
  public class AsyncExec : Exec
  {
    #region Task Members
    protected override int ExecuteTool(string pathToTool, string responseFileCommands, string commandLineCommands)
    {
      Process process = new Process();
      process.StartInfo = GetProcessStartInfo(pathToTool, commandLineCommands);
      process.Start();
      return 0;
    }
    #endregion

    #region Methods
    protected virtual ProcessStartInfo GetProcessStartInfo(string executable, string arguments)
    {
      if (arguments.Length > 0x7d00)
      {
        this.Log.LogWarningWithCodeFromResources("ToolTask.CommandTooLong", new object[] { base.GetType().Name });
      }
      ProcessStartInfo startInfo = new ProcessStartInfo(executable, arguments);
      startInfo.WindowStyle = ProcessWindowStyle.Hidden;
      startInfo.CreateNoWindow = true;
      startInfo.UseShellExecute = true;
      string workingDirectory = this.GetWorkingDirectory();
      if (workingDirectory != null)
      {
        startInfo.WorkingDirectory = workingDirectory;
      }
      StringDictionary environmentOverride = this.EnvironmentOverride;
      if (environmentOverride != null)
      {
        foreach (DictionaryEntry entry in environmentOverride)
        {
          startInfo.EnvironmentVariables.Remove(entry.Key.ToString());
          startInfo.EnvironmentVariables.Add(entry.Key.ToString(), entry.Value.ToString());
        }
      }
      return startInfo;
    }
    #endregion
  }
}

Don't fret over the WindowStyle and CreateNoWindow flags, Exec works by spawning cmd.exe with a batch file that it generates with our command. Without those flags, the command prompt window flashes by.

Obviously, very rough stuff and I make no promises of it's abilities. It worked for the simple example below and that's all I wanted. Ideally, the task would ensure the executable being started exists so we could at least fail if that's the case. But, for now this works for us. It's only used in interactive situations to spawn NCoverExplorer and things like thing. We can already easily spawn the HTML reports by using:

<Exec Command="$(ArtifactsDirectory)\mbunit-tests.html" />

But that just doesn't work when you need to run an application and not care about when it's closed:

<AsyncExec Command="$(ToolsDirectory)\NCoverExplorer\NCoverExplorer.exe $(ArtifactsDirectory)\coverage.xml" />

So here's the binaries in case somebody else is curious as well as the UsingTask.

<UsingTask AssemblyFile="AsyncExec.dll" TaskName="AsyncExec.AsyncExec" />

Obviously, if something like this is already easily possible and this was a half hour wasted, let me know. Especially if it's possible "out-of-the-box". I'm always glad to have one less dependency.

Source and Binaries

source | tools | msbuild
by Jacob on Thursday, March 01, 2007 12:52:18 PM (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [1]  |  Trackback
 Sunday, February 25, 2007

Roy Osherove brings up several good points with regards to the preached design methodology of old and the new testable design some of us have come to know and love lately.

I think that TDD really helps to eliminate a large number of these issues. If you test everything yourself, then inherently your API is testable. Unfortunately, as Jonathan Cogley points out, TDD is not yet mainstream.

A nice side effect of having a testable API or application is that often times your code is also extensible. The thing that blocks it from being fully testable and extensible are those darn sealed and internal keywords, and of course, not making things virtual that really should be. Even open source projects are guilty of not having testable or extensible enough APIs. Yes, Castle MonoRail provides AbstractMRTestCase, but that actually uses ASP.NET and is way more heavy than I like.

Here is our base class for Controller Tests. This allows you to unit test nearly every aspect of your controller, without ever hitting ASP.NET. Notice the lovely and necessary use of reflection? In order to mock the context, you'll want to call InitializeController and pass it the controller you're testing, but be sure to do it in your _mocks.Unordered block (we almost ALWAYS use mocks.Unordered... it makes tests more readable and ensures that you're tests aren't too tightly coupled with your implementation, but that's the subject for another post.)

  public class EleutianControllerTests
  {
    #region Constants
    private const string ApplicationPhysicalPath = "Q:\\PhysicalPath";
    #endregion

    #region Member Data
    protected string _virtualDirectory = String.Empty;
    protected MockRepository _mocks;
    protected IControllerServices _controllerServices;
    protected IRailsEngineContext _context;
    protected IRequest _request;
    protected IResponse _response;
    protected IServerUtility _serverUtility;
    protected IDictionary _session;
    protected Flash _flash;
    protected NameValueCollection _parameters;
    #endregion

    #region Test Setup and Teardown Methods
    [SetUp]
    public virtual void Setup()
    {
      _mocks = new MockRepository();
      _context = _mocks.CreateMock<IRailsEngineContext>();
      _request = _mocks.DynamicMock<IRequest>();
      _response = _mocks.DynamicMock<IResponse>();
      _serverUtility = _mocks.DynamicMock<IServerUtility>();
      _session = _mocks.DynamicMock<IDictionary>();
      _flash = new Flash();
      _parameters = new NameValueCollection();
    }

    protected void InitializeController(Controller controller, string areaName, string controllerName, string actionName)
    {
      BindingFlags bindingFlags = BindingFlags.FlattenHierarchy | BindingFlags.Instance | BindingFlags.NonPublic |
                                  BindingFlags.InvokeMethod;

      MethodInfo method = controller.GetType().GetMethod("InitializeControllerState", bindingFlags);
      method.Invoke(controller, new object[] { areaName, controllerName, actionName });

      FieldInfo field = controller.GetType().GetField("context", bindingFlags);
      field.SetValue(controller, _context);

      field = controller.GetType().GetField("serviceProvider", bindingFlags);
      field.SetValue(controller, _context);

      InitializeRailsContext(areaName, controllerName, actionName);
    }

    protected void InitializeRailsContext(string areaName, string controllerName, string actionName)
    {
      Expect.Call(_context.UrlInfo).Return(
        new UrlInfo("eleutian.com", "www", _virtualDirectory, "http", 80,
                    Path.Combine(Path.Combine(areaName, controllerName), actionName), areaName, controllerName,
                    actionName, "rails")).Repeat.Any();
      Expect.Call(_context.GetService(typeof(IUrlBuilder))).Return(new DefaultUrlBuilder()).Repeat.Any();
      Expect.Call(_context.Server).Return(_serverUtility).Repeat.Any();
      Expect.Call(_context.Flash).Return(_flash).Repeat.Any();
      Expect.Call(_context.ApplicationPath).Return("/").Repeat.Any();
      Expect.Call(_context.Request).Return(_request).Repeat.Any();
      Expect.Call(_context.Response).Return(_response).Repeat.Any();
      Expect.Call(_context.ApplicationPhysicalPath).Return(ApplicationPhysicalPath).Repeat.Any();
      Expect.Call(_request.Params).Return(_parameters).Repeat.Any();
      Expect.Call(_context.Session).Return(_session).Repeat.Any();
    }
    #endregion
  }

Oh, and back to the original point of the post. Please, please don't mark things internal or sealed unless you have a very good reason to do it. And no, I don't think that "We can't afford to support it" is a good enough reason. Also, "We're afraid the user might break something" is DEFINITELY not a good enough reason. We know what we're getting into when we extend APIs... we're all developers here.

by Aaron on Sunday, February 25, 2007 4:16:47 PM (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [4]  |  Trackback
 Thursday, February 22, 2007

I've been writing a lot of tests lately because our code coverage isn't up to where we'd like it. NCover+NCoverExplorer is a pretty awesome and while it does have its quirks it has been incredibly useful. A lot of my adventures in writing tests is creating tons of RhinoMocks so that I can pass them to constructors and that sort of thing. So I got a strange idea, and I'm not sure how I feel about it necessarily and figured I'd propose it to all of you out there and get your thoughts.

Basically, 99% of the time in a services unit test, all the interfaces passed to the service will be mocks, so we end up with lots of functions that look like this:

[SetUp]
public void Setup()
{
  _service1 = _mocks.CreateMock<IService1>();
  _service2 = _mocks.CreateMock<IService2>();
  _service3 = _mocks.CreateMock<IService3>();
  _serviceWeAreTesting = new DefaultServiceWeAreTesting(_service1, _service2, _service3);
}

If we do this a lot for DefaultServiceWeAreTesting, it's often refactored to a single location. All in all, it can be very repetitive to create all the mocks. So, as an experiment I decided to leverage the power of the IoC container, in our case Windsor, to take care of a lot of the mundane for me. In the end I end up with this code:

[SetUp]
public void Setup()
{
  _mocks = new MockRepository();
  _container = new AutoMockingContainer(_mocks);
  _service = _container.Create<DefaultServiceWeAreTesting>();
}

AutoMockingContainer is simply a WindsorContainer with a custom facility and dependency resolver that supplies a RhinoMock for any interface that is resolved. We've also moved the setup code into a base class AutoMockingTests that has the container and mock repository. We can then write code that uses the mocks from the container:

[Test]
public void DoWork_Always_AsksOtherServices()
{
  using (_mocks.Unordered())
  {
    _container.Get<Service1>().DoWork();
    _container.Get<Service2>().DoWork();
    _container.Get<Service3>().DoWork();
  }
  _mocks.ReplayAll();
  _service.DoWork();
  _mocks.VerifyAll();
}

Of course, you don't have to always do the Get call on the container, you can do that in the Setup and use member variables, etc... the point is, the mocked services are created for us. We can also mark other types so that they aren't tested, and take advantage of the IoC and injection that we use in our application to speed up writing and maintaining tests. The implementation I've uploaded allows you to associate a particular strategy with service dependencies. They are:

  • StubbedStrategy: A mock will be created, then for each property a GetValue expectation (with Repeat.Any) will be added to return a value for that property. The value will be retrieved like any other dependency (it's strategy will be gotten, and the value from that)
  • DynamicStrategy (default): A DynamicMock will be created for the dependency.
  • StandardStrategy: A standard mock from CreateMock.
  • NonMockedStrategy: Automatically set for any service that is registered normally with the container - a standard container resolve.

So, pros and cons? To get things started:

Pros

  1. Can be easier to maintain and write tests. Adding a dependency or changing the constructor breaks tests in ways that the production environment can usually handle just fine.
  2. Automatic testing the services construction via the IoC container.

Cons

  1. Speed/peformance? Does making the container such an integral part of the test fixtures hurt performance? Setup has to be longer when we're creating the container the way we are. Does this matter? Only as long as the time saved when writing tests is larger than the time it takes to run them, which I'm sure is the case...

What do you think? So far we really like the idea, or at least think it's interesting. Here are the sources:

Source and Binaries

by Jacob on Thursday, February 22, 2007 7:04:26 PM (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [8]  |  Trackback
 Tuesday, February 20, 2007

I spent yesterday and today refactoring the code for the Controller Action/View map generator tool. I made some improvements, wrote some tests and I'm pleased to announce the first release. I saw Brian had implemented his as an MsBuild task and I liked that idea, so that's how ours runs now. First, things aren't as "drop in and go" as I would like because it's still evolving in and around our, already large, code base. It's my hope that over time the tool evolves as peoples needs change, etc... we can add some more configuration, that sort of thing. I'm more than willing to hear suggestions and such. Anway, here we go...

So in order to get yourself up and running, you'll need to do a few things. First, you'll need to add the task to your MsBuild. Simply open your csproj and add the following:

<UsingTask TaskName="Eleutian.Tools.CodeGenerator.MsBuild.GenerateMonoRailSiteTreeTask" AssemblyFile="Eleutian.Tools.CodeGenerator.dll" />
<ItemGroup>
  <ViewSources Include="../YourViewsDirectory/**/*.brail">
    <InProject>false</InProject>
  </ViewSources>
</ItemGroup>
<ItemGroup>
  <ControllerSources Include="Controllers/**/*.cs">
    <InProject>false</InProject>
  </ControllerSources>
</ItemGroup>
<Target Name="BeforeBuild" Inputs="@(Compile)" Outputs="$(ProjectDir)\SiteMap.generated.cs">
  <GenerateMonoRailSiteTreeTask File="SiteMap.generated.cs" Namespace="YourNamespace.SiteMap" ControllerSources="@(ControllerSources)" ViewSources="@(ViewSources)">
  </GenerateMonoRailSiteTreeTask>
</Target>

You'll notice a few things in here. ViewSources is just the collection of view files (be it .vm or .brail, etc..). It will use the paths of those files to add the View nodes into the map. ControllerSources is the C# source files for your controllers only, specifying this helps speed up parsing. I'll get to why in a bit. And for the Sources attribute on the task you should specify all the sources in the assembly, which @(Compile) works great for.

With the task added, you should be able to build and have a SiteMap.generated.cs file, now you'll need to tweak your "base" Controller class. If you're like us, you have a Controller class that you made yourself that all of your Controller's inherit from. In that class you'll need to add some code like the following:

private ICodeGeneratorServices _services;

public ICodeGeneratorServices CodeGeneratorServices
{
  get { return _services; }
}

public RootAreaNode Site
{
  get { return new RootAreaNode(this.ControllerServices); }
}

protected virtual void PerformGeneratedInitialize()
{
  _services = new DefaultCodeGeneratorServices(
    new DefaultControllerReferenceFactory(),
    new AspDotNetRedirectService()
  );
  _services.Controller = this;
}

First is the member variable, _services. You can do this however you like, but it's consumed by the ControllerAction/ViewReference classes to do various likes. CodeGeneratorServices is a property the partial controller code uses to create the MyActions and MyViews node instances. Site is just an easy way to get the top, root level node. PerformGeneratorInitialize is overridden in the partial controller classes to add the MyViews and MyActions nodes to the PropertyBag so they are available in the views. So there you go. If I'm not missing anything, that should do the trick. Let me know if I did and I'll append to this post.

Oh, the reason for specifying the ControllerSources is to cut down on the number of classes/types we visit when generating the internal "tree" that the source code is generated from. At first glance it seems like you should just be able to parse the ControllerSources only. We coudln't really do that because we needed to gather information on the other types in the assembly so we'd be able to use them in the arguments of our actions, etc... 

I have to stress that the code is relatively new, having undergone a major refactor to isolate it from the rest of our project. I make no promises that I won't have to upload a new copy, with a fix. :)

Source and Binaries

by Jacob on Tuesday, February 20, 2007 6:36:46 PM (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [4]  |  Trackback
 Sunday, February 18, 2007

Hello everyone. I just wanted to let those who responded to the string literal posts know what was "going on". Basically, we're still trying to find a way that we can release the source to some of our tools. I apologize for dragging my feet. I manage to keep pretty busy. Heh.

I was catching up on the castle-project's mailing list and found this post by Lee Henson. He's tossed together an implementation of a PropertyBag wrapper generator and posted the source. It's very similar to our approach. One main difference is that we do our generation at runtime so we don't have to generate and reference another assembly. We have an IViewFactory interface and a PropertyBagViewFactory implementation that hands them out. In tests we have an IViewFactory that pulls the views out of the MockRepository.

Incidentally, our code that does this lies with some other code for generating Control.Invoke proxies for our System.Windows.Forms view interfaces. It seems we're not the only people who do that particular type of generation. RĂ¼diger Klaehn has an article here about it. I strongly suggest reading it if you do any kind of SWF work.

In the thread I found a link to Brian Romanko's post about his implementation of the controller action/view SiteMap, as well as the PropertyBag wrapper. So just in case anybody gets impatient they can find something to tinker with over there. While his implementation is different from ours, the end result is very similar. I like his idea of generating a property for actions to refer to them without parameters.

I mentioned that for the SiteMap code generation we used CodeDom. CodeDom is great and means we don't have to use StringBuilder to construct C#. It also abstracts the language away. For those who are interested in this kind of code inspection/generation, I strongly suggest taking a look at N Refactory, it's a great library for parsing C#/VB.NET source. It's what we use and I've been incredibly happy with it. The only real hurdle when doing that kind or work is type resolution. I'll try and make a post about that in the near future.

by Jacob on Sunday, February 18, 2007 7:04:16 PM (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [1]  |  Trackback
 Friday, February 02, 2007

As promised, here's the plugin I was talking about and the Rhino Mocks templates.

Rhino Mocks Templates - Import these in your Template config.

Plugin - Drop this in your "%PROGRAMFILES%\Developer Express Inc\DXCore for Visual Studio .NET\2.0\Bin\Plugins" Oh, and yeah I know it's named after only one of the commands in there, but I was too lazy after I added the other commands to rename the project. You'll see the new commands in the Template configuration in the Command dropdown.

Plugin Source - I know, not the source you want from us right now and it's pretty ugly, but it's a start, right?

by Aaron on Friday, February 02, 2007 6:00:18 PM (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [0]  |  Trackback