Posterous theme by Cory Watilo

Filed under: Tutorial

Adding MvcContrib SubControllers to your ASP.NET MVC Project

After a little bit of work with MVC, you get infected with the spirit of clean code and begin to desire even more ways of eliminating repetition. You’ve got partials and html helpers. Still you are hungry. SubControllers are the dish that will fill you up.

Why SubControllers?

There’s a design decision here. The question is why are we designing with subcontrollers? To understand the rationale, let’s look at the qualities of the various sub-view options.

  • Partial Views – partial views are probably the most useful method for re-using view output. They are very easy to set up, and are very versatile. However, they don’t contain logic. They are intended entirely as a slave to the Action Controller. They get their model from the controller and simply render it. This means that the controller needs to know and provide everything the partial view needs. Not good for something like a login status control, which is an separate concern from most controllers.
  • HTML Helpers – HTML helpers get used a lot, and they are very helpful for creating your own ‘controls’ to use in your pages. They do not, however, support using a view template. This means you’ve got to create them and test them with tests for emitted markup. This adds a lot of complexity if you are trying to do something more than create a html rendering function. Not a good place to insert complex view logic, like a shopping cart status widget, or anything with a table or list. The HTML helper also still gets it’s data from the master view/controller, so it fails at separating concerns.
  • Html.RenderAction() – RenderAction is the once and future solution to a number of problems. Or so I hear. I have trouble getting excited about using it right now. Currently, it is not baked into MVC, but rather is in the separate ‘MVC Futures’ assembly, where it is unsupported. Rumor is it is buggy and unsecure. In the future it may be changed or dropped or renamed or anything. ScottGu has promised in a blog comment that it is due for inclusion in MVC 2. However, I don’t program to unreleased Microsoft products. Maybe later, but for now…
  • MvcContrib SubController – Jeff Palermo implemented subcontrollers for MvcContrib to give us a working solution—now—for reusable view/controller code. Subcontrollers have their own model, ViewData, are nestable, and can use view templates for their output. If you have a job that goes beyond a partial view, or a html helper, SubControllers are a peach.

Setting Up Your Project

1) Add a reference to MvcContrib.

2) Create a class called StructureMapSubControllerBinder. This is only required if you’re using StructureMap to do your IOC for you. You can use the base SubControllerBinder from MvcContrib, or create your own version for your IOC tool.

public class StructureMapSubControllerBinder
: SubControllerBinder
{
public override object CreateSubController(Type
destinationType)
{
object instance = ObjectFactory.GetInstance(destinationType);
if (instance == null)
{
throw new InvalidOperationException(destinationType
+ " not registered with StructureMap");
}

return instance;
}
}

 

3) Make the SubControllerBinder your default binder.

ModelBinders.Binders.DefaultBinder = new StructureMapSubControllerBinder();
4) Add a reference to the MvcContrib namespace to the Pages section of Web.Config. This will save you putting a lot of namespace tags in your views.
<add namespace="MvcContrib"/>

Creating a SubController

1) Create a ~/Controllers/SubControllers folder. This is completely optional. If you have a bigger project you might want to make multiple subcontrollers folders for different areas.

2) Create a SubController class. The action needs to have the ‘same’ name as the class. It also subclasses from SubController.

using System.Web.Mvc;
using MvcContrib;

namespace NWIS.Business.Web.Controllers.SubControllers
{
public class DemoSubController
: SubController
{
public ViewResult Demo()
{
return View();
}
}
}

3) Create a View subfolder. Using the ‘Add View’ context menu from the controller won’t work because the ‘sub’ in the class name. Just create the folder yourself. ~/Views/Demo.

4) Create a View. Right click on the ~/Views/Demo folder. Select Add->View. Name the view ‘Demo’. Make it a partial view (.ascx). Go ahead an add some markup to the view. Whatever you like.

Using the SubController in your View

1) Add an attribute to your Controller class.

[SubControllerActionToViewDataAttribute]

2) Add the subcontroller as a parameter to the action you want to use it in.

public ViewResult
Index(DemoSubController mySubCont)

3) Place the subcontroller output into your view.

<% ViewData.Get<Action>("mySubCont").Invoke();
%>
The name you use here is the name of the parameter to the controller action.

That should be it. You subcontroller can output into your view, and you can use it in many, many controllers and actions. You can add dependencies directly to the subcontroller in it’s constructor. You can also pass information from the action to the subcontroller using properties.

Resources

StructureMap: IRepository and Test Data Injection

I Love StructureMap! It’s wonderful. What a way to compose your code together easily, precisely, and consolidatedly (!!). When I put a sentence like that together, I wonder if I even know what I’m talking about. The problem with StructureMap, IoC, and dependency injection really seems to be that the jargon for the patterns is so manifestly true that once you learn what the hell you are doing, you are completely unable to stop talking about it in shorthand. And that shorthand makes absolutely no sense to someone who hasn’t absorbed the patterns. Keep plugging, people. Once you do it, you’ll get it. Then you’ll be there and not be able to explain to other people why you’re so right. It’s like being Tom Cruise and needing to explain scientology.

Anyways.

I learned two things today. The first is how to hook all of my concrete generic repository types together with their interfaces. I had been adding a line of configuration for each repository. Now my test code looks like this:

ForRequestedType(typeof(IRepository<>)).TheDefaultIsConcreteType(typeof(ListRepository<>));

And my production code:

ForRequestedType(typeof(IRepository<>)).TheDefaultIsConcreteType(typeof(LlblRepository<>));

That’s easy!

The other thing I learned is that I can happily and easily inject data into my object registry for testing purposes. I have an in-memory repository implementation built. All it needs is data.

public class MemoryDataSource
{
private Dictionary<Type, IQueryable> data;

public MemoryDataSource(Dictionary<Type, IQueryable>
data)
{
this.data = data;
}

public IQueryable GetQueryable(Type type)
{
return this.data[type];
}
}
public class ListRepository<T>
: IRepository<T>
{
private MemoryDataSource source;

public ListRepository(MemoryDataSource source)
{
this.source = source;
}

public IQueryable<T> GetSource()
{
return ((IQueryable<T>)source.GetQueryable(typeof(T)));
}

public void SaveEntity(T
entity)
{
return;
}
}

Now all I need to do is build a Dictionary<> keyed on the entity object type and fill it up with data. Once I’ve done that, I just pass it into the StructureMap registry like this:

ObjectFactory.Inject<Dictionary<Type, IQueryable>>(dataSource);

Now I can have ObjectFactory construct my object under test and it’s got just the data I need it to have.

Adding MVC to an existing ASP.NET Application

ASP.NET MVC Has added a very useful new programming model to developing websites in .NET. There is hype and debate all throughout the interwebs on how great MVC is. And it all can be yours, with nothing but a ‘File->New’ in Visual Studio….unless you already have an ASP.NET application. In which case, you need to do a bit more work.

  1. Add project references to:
    System.Web.Abstractions
    System.Web.Mvc
    System.Web.Routing
  2. Create /Controllers, /Views, and /Views/Shared folders in your project
  3. Update web.config
    <?xml version="1.0" encoding="utf-8" ?>
    
    <configuration>
    
    <system.web>
    
    <pages>
    
    <namespaces>
    
    <add namespace="System.Web.Mvc"/>
    
    <add namespace="System.Web.Mvc.Ajax"/>
    
    <add namespace="System.Web.Mvc.Html" />
    
    <add namespace="System.Web.Routing"/>
    
    <add namespace="System.Linq"/>
    
    <add namespace="System.Collections.Generic"/>
    
    </namespaces>
    
    </pages>
    
    <compilation>
    
    <assemblies>
    
    <add assembly="System.Core,
    Version=3.5.0.0,
    Culture=neutral,
    PublicKeyToken=B77A5C561934E089"/>
    
    <add assembly="System.Web.Mvc,
    Version=1.0.0.0,
    Culture=neutral,
    PublicKeyToken=31bf3856ad364e35" />
    
    <add assembly="System.Web.Abstractions,
    Version=3.5.0.0,
    Culture=neutral,
    PublicKeyToken=31BF3856AD364E35"/>
    
    <add assembly="System.Web.Routing,
    Version=3.5.0.0,
    Culture=neutral,
    PublicKeyToken=31BF3856AD364E35"/>
    
    </assemblies>
    
    </compilation>
    
    <httpModules>
    
    <add name="UrlRoutingModule"
    
    type="System.Web.Routing.UrlRoutingModule,
    System.Web.Routing,
    Version=3.5.0.0,
    Culture=neutral,
    PublicKeyToken=31BF3856AD364E35" />
    
    </httpModules>
    
    </system.web>
    
    <system.webServer>
    
    <validation validateIntegratedModeConfiguration="false"/>
    
    <modules runAllManagedModulesForAllRequests="true">
    
    <remove name="ScriptModule" />
    
    <remove name="UrlRoutingModule" />
    
    <add name="ScriptModule" preCondition="managedHandler"
    
    type="System.Web.Handlers.ScriptModule, 
    
    System.Web.Extensions, Version=3.5.0.0, Culture=neutral, 
    
    PublicKeyToken=31BF3856AD364E35"/>
    
    <add name="UrlRoutingModule"
    
    type="System.Web.Routing.UrlRoutingModule,
    System.Web.Routing, 
    
    Version=3.5.0.0, Culture=neutral, 
    
    PublicKeyToken=31BF3856AD364E35" />
    
    </modules>
    
    <handlers>
    
    <remove name="WebServiceHandlerFactory-Integrated"/>
    
    <remove name="ScriptHandlerFactory" />
    
    <remove name="ScriptHandlerFactoryAppServices" />
    
    <remove name="ScriptResource" />
    
    <remove name="MvcHttpHandler" />
    
    <remove name="UrlRoutingHandler" />
    
    <add name="ScriptHandlerFactory" verb="*" path="*.asmx"
    
    preCondition="integratedMode"
    
    type="System.Web.Script.Services.ScriptHandlerFactory, 
    
    System.Web.Extensions, Version=3.5.0.0, Culture=neutral, 
    
    PublicKeyToken=31BF3856AD364E35"/>
    
    <add name="ScriptHandlerFactoryAppServices" verb="*"
    
    path="*_AppService.axd" preCondition="integratedMode"
    
    type="System.Web.Script.Services.ScriptHandlerFactory, 
    
    System.Web.Extensions, Version=3.5.0.0, Culture=neutral, 
    
    PublicKeyToken=31BF3856AD364E35"/>
    
    <add name="ScriptResource" preCondition="integratedMode"
    
    verb="GET,HEAD" path="ScriptResource.axd"
    
    type="System.Web.Handlers.ScriptResourceHandler, 
    
    System.Web.Extensions, Version=3.5.0.0, Culture=neutral, 
    
    PublicKeyToken=31BF3856AD364E35" />
    
    <add name="MvcHttpHandler" preCondition="integratedMode"
    
    verb="*" path="*.mvc" type="System.Web.Mvc.MvcHttpHandler, 
    
    System.Web.Mvc, Version=1.0.0.0, Culture=neutral, 
    
    PublicKeyToken=31BF3856AD364E35"/>
    
    <add name="UrlRoutingHandler"
    
    preCondition="integratedMode" verb="*" path="UrlRouting.axd"
    
    type="System.Web.HttpForbiddenHandler,
    System.Web, 
    
    Version=2.0.0.0, Culture=neutral, 
    
    PublicKeyToken=b03f5f7f11d50a3a" />
    
    </handlers>
    
    </system.webServer>
    
    </configuration>
  4. Add the following to Global.asax.cs (create a Global.asax if you don’t already have one)
    public static void RegisterRoutes(RouteCollection
    routes)
    {
    routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
    routes.IgnoreRoute("{resource}.aspx/{*pathInfo}");
    
    routes.MapRoute(
    "Default", //
    Route name
    
    "{controller}/{action}/{id}", //
    URL with parameters
    
    new { controller = "Home",
    action = "Index", id = "" } //
    Parameter defaults
    
    );
    
    }
    
    protected void Application_Start()
    {
    RegisterRoutes(RouteTable.Routes);
    }

    The above is the “standard” routing for a MVC site. It will work, but it might cause you trouble if you want the root of your website to still go to a ‘default.aspx’. Try this line instead:
    routes.MapRoute(
    "Default", 
    
    "MVC/{controller}/{action}/{id}", 
    
    new { controller = "Home",
    action = "Index", id = "" }
  5. Edit your .csproj file by hand
    <ProjectTypeGuids>{603c0e0b-db56-11dc-be95-000d561079b0};{349c5851-65df-11da-9384-00065b846f21};{fae04ec0-301f-11d3-bf4b-00c04f79efbc}</ProjectTypeGuids>

    This will tell Visual Studio to act like this is an MVC project. You will get the context menu items for MVC in your Controllers and Views directories.
    Note: I’ve had trouble at this point with some Visual Studio installs. If you’re having trouble with “The project type is not supported by this installation.” messages here, it may be time for a clean install in a fresh VM.
  6. Set Up IIS. If you’re using IIS7, the System.Webserver settings in your Web.Config file should have taken care of this step. If you’re going to need to map the wildcard URL to aspnet_isapi.dll in order to get all of the MVC routing magic to work.
  7. You might want to copy of the /Views/web.config file from an existing MVC project to prevent your views from being viewed directly, rather than through their controllers.
  8. You might also wish to create a /Scripts folder and copy over the contents of the /Scripts folder from native MVC project. It has the jquery and MS AJAX javascripts that you may be looking for if you’re following a MVC book or tutorial.

Boy howdy. That was a good chunk of work. But now you have the infinite pleasure of developing in MVC, and your old web site should continue to work under you. Delicious incremental development goodness.

Resources

Windows Forms Eventing: Generic Pub/Sub

In my last post, I covered how you can implement a publish/subscribe system for sending events between components of your Windows Forms application. Using this model, it is easy to create separate components that don’t rely on each other’s implementation details in order to provide a consistent experience for the user. A button on the toolbar can be disabled by an action on the data entry screen…without hard references between the two.

However, the implementation from last time required a new aggregator and set of interfaces for each message type that needed to be passed around. Let’s fix that with generics.

Listener Interface

First we replace the IEventReciever interface from last time with a generic IListener interface that uses a generic type for the message object.

public interface IListener<T>
{
void Handle(T message);
}
All your subscribers now implement an IListener<Message> for each message type they can handle. (This is great because one class can listen for multiple types of messages!)

Event Aggregator Interface

Similarly, the Event Aggregator needs a generics reset. Notice that the Add and Remove methods now accept any old object.

public interface IEventAggregator
{
void SendMessage<T>(T message);
void AddListener(object listener);
void RemoveListener(object listener);
}

Event Aggregator

public class EventAggregator
: IEventAggregator
{
private readonly List<object>
listeners = new List<object>();

#region IEventAggregator Members

public void SendMessage<T>(T
message)
{
listeners.CallOnEach<IListener<T>>(x => { x.Handle(message); });
}

public void AddListener(object listener)
{
if (listeners.Contains(listener)) return;
listeners.Add(listener);
}

public void RemoveListener(object listener)
{
listeners.Remove(listener);
}

#endregion

}

Not much new here….except for that CallOnEach method. Where did that come from?

Extension Methods

We need to add a few utility methods to the IEnumerables so that we can send our messages:

public static void CallOnEach<T>(this IEnumerable
enumerable, Action<T> action) where T : class

{
foreach (object o in enumerable)
{
o.CallOn(action);
}
}

public static void CallOn<T>(this object target,
Action<T> action) where T : class

{
var subject = target as T;
if (subject != null)
{
action(subject);
}
}

Put those in a likely static class somewhere.

Are we there yet?

This Event Aggregator is getting powerful. We should kill it before it develops language skills.

With the code we have so far, we can easily create a new message in the system without modifying the aggregator code. I like adding the methods as child classes of their receivers (when they are receiver-specific).

There is, however, still a problem. In the type of application that needs this eventing system, you are likely going to need to do some background threading to keep the UI responsive. The Event Aggregator we have doesn’t do anything to keep itself or the rest of the application synchronized.

What happens when a background thread sends a message that the receiver needs to act on by talking to the UI thread? Do you write a bunch of Invoke() code everywhere?

As it turns out, there is a better way. And my next post will show you how to upgrade your EventAggregator to be the thread master!

Windows Forms Eventing: Adding Pub/Sub

In my last post, I described the creeping problem I’ve been having with wiring my large Windows Forms application up with EventHandler delegates. In short, the design becomes brittle—it’s hard to write and hard to change. Luckily, the solution is an easy one: Publish/Subscribe.

The Event Aggregator is a singleton. You can either manage this yourself, or you can have your Inversion of Control container do it for you. When an Event Receiver is created, it registers itself with the Event Aggregator, which stores a reference to the receiver. When a Event Sender sends a message to the Event Aggregator, the aggregator loops through all the registered receivers and calls a method on them to handle the event. This is facilitated by having the receivers implementing an interface. Here’s a simple implementation:

public class EventMessage
{
public string MessageText
{ get; set; }
}

public interface IEventReceiver
{
void Handle(EventMessage message);
}

public interface IEventAggregator
{
void SendMessage(EventMessage message);
void AddReceiver(IEventReceiver receiver);
void RemoveReceiver(IEventReceiver receiver);
}

public class EventAggregator
: IEventAggregator
{
private readonly List<IEventReceiver>
receivers = new List<IEventReceiver>();

#region IEventAggregator Members
public void SendMessage(EventMessage
message)
{
receivers.ForEach(r => r.Handle(message));
}

public void AddReceiver(IEventReceiver
receiver)
{
if (receivers.Contains(receiver)) return;
receivers.Add(receiver);
}

public void RemoveReceiver(IEventReceiver
receiver)
{
receivers.Remove(receiver);
}
#endregion

}

public class EventReceiver
: IEventReceiver
{
public EventReceiver(IEventAggregator aggregator)
{
aggregator.AddReceiver(this);
}

#region IEventReceiver Members
public void Handle(EventMessage
message)
{
Console.WriteLine(message.MessageText);
}
#endregion

}

public class EventSender
{
private IEventAggregator aggregator;

public EventSender(IEventAggregator aggregator)
{
this.aggregator = aggregator;
}

public void SendErrorMessage(string message)
{
aggregator.SendMessage(new EventMessage { MessageText
= message });
}
}

This is a big improvement over manual event wiring through an application. No longer do the targets of a message need to know (have references to) the senders of the message in order to make the connection. You can add a new target (receiver) without changing the code of the sender. You can add a new sender without changing the code of the receivers. And you don’t have to manually map things out in some sort of registry class. This is simple easy and it will work.

It’s always something with you, isn’t it?

Ok. I like it. I’m happy. But how many of these things am I going to have floating around? It seems like a lot of code to write to hand one type of event between some components. I’m going to have to hire some Indian outsourcing company to write all of these singleton aggregators.

This sounds like a job for generics! My next post will rewrite the Event Aggregator so that a single aggregator can handle every message your application has.

Windows Forms Eventing: The Problem

Anxiety. This is a feeling I’ve been learning to recognize as a SIGN when I’m coding. The feeling you get when the camera gets really close on the face of the pretty girl as she walks around the empty, and silent, house. Is she going to turn around suddenly and be given flowers? Or is the disemboweling only moments away. You don’t know, but you’re cringing either way.

I’ve felt this in the past about data access layers. This is the feeling I’ve been accumulating around my Windows Forms application lately. I don’t want to code. I’m afraid to code. It’s going to be painful. I’m not sure what’s going to go wrong. But something will, and I’ll be sucked into the unproductive death pit.

Having spent a bit of time feeling around the problem, I’m pretty sure what I don’t like is having to deal with events. Let’s take a look at the reason why:

Windows forms makes things easy.

Click click click! I have a button and I have an event linked to it. Amazingly productive. My app will be running in no time.

Event Handlers are teh awesome.

It’s so easy to link an action to an event handler. Well. It’s pretty easy. It’s very easy within one class. Not so bad if you’ve got a reference to the object that contains the event handler. A little bit of encapsulation makes it harder. Chained event handlers can fix that though……

All is happy with one form per task.

This form is easy. Add a few buttons and it’s great. If you’re prepared to make your application out of a bunch of forms that the user will work with one-by-one, there’s no problem.

However….sovereign apps don’t look like that.

If the user is going to be in one application all day long, it will have to provide easy access to a number of different types of functionality. The application can’t consolidate all of the interface elements required for a single task into a single place. Rather there’s a spaghetti monster of functionality, reaching it’s noodley appendages everywhere.

Events flying every which way, and everything needs a hard reference to everything else.

Can you actually wire all this up with EventHandler references? Sure. Of course you can. However, you end with a lot of tightly coupled code that is a real mess to create and to maintain.

Hope. The eternal struggle.

A application shell is a complicated beast. But problems have solutions. In my next post, I’ll show how you can integrate all these separate components without strangling yourself in wiring.

Adding ELMAH to an ASP.NET Site

ELMAH (Error Logging Modules and Handlers) is a fantastic library that provides error logging and troubleshooting support to an ASP.NET web site. You practically just drop it in and BOOM, you’ve got great exception reporting.

Step 1: Add A Reference

Add a reference to the ELMAH DLL in your ASP.NET project. (They tell me it just needs to be dropped in the BIN folder, but that almost seems like more work to me.)

Step 2: Add Config Sections

In web.config, add the following lines to <configSections>

<configSections>
<sectionGroup name="elmah">
<section name="security" requirePermission="false" type="Elmah.SecuritySectionHandler,
Elmah"/>
<section name="errorLog" requirePermission="false" type="Elmah.ErrorLogSectionHandler,
Elmah" />
<section name="errorMail" requirePermission="false" type="Elmah.ErrorMailSectionHandler,
Elmah" />
<section name="errorFilter" requirePermission="false" type="Elmah.ErrorFilterSectionHandler,
Elmah"/>
</sectionGroup>
</configSections>

Step 3: Add the ELMAH Section

<elmah>
<security allowRemoteAccess="0" />
<errorLog type="Elmah.XmlFileErrorLog,
Elmah" logPath="|DataDirectory|" />
</elmah>

Step 4: System.web—httpModules and httpHandlers

<system.web>
<httpModules>
<add name="ErrorLog" type="Elmah.ErrorLogModule,
Elmah"/>
</httpModules>
<httpHandlers>
<add verb="POST,GET,HEAD" path="elmah.axd" type="Elmah.ErrorLogPageFactory,
Elmah" />
</httpHandlers>
</system.web>

Step 5: (II7 Only) Configure system.webServer

<system.webServer>
<validation validateIntegratedModeConfiguration="false" />
<modules>
<add name="Elmah.ErrorLog" type="Elmah.ErrorLogModule,
Elmah" preCondition="managedHandler" />
<add name="Elmah.ErrorFilter" type="Elmah.ErrorFilterModule" preCondition="managedHandler" />
<add name="Elmah.ErrorMail" type="Elmah.ErrorMailModule" preCondition="managedHandler" />
</modules>
<handlers>
<add name="Elmah" path="elmah.axd" verb="POST,GET,HEAD" type="Elmah.ErrorLogPageFactory,
Elmah" preCondition="integratedMode" />
</handlers>
</system.webServer>

Step 6: Secure remote access using ASP.NET membership

<location path="elmah.axd">
<system.web>
<authorization>
<deny users="?"/>
</authorization>
</system.web>
</location>

Resources:

I don’t know what a number is anymore!

One, Two, Three, Four. I thought I understood the damn things. And then it turns out they have ‘lifestyle choices’ and Mr. One says ‘you know, I just don’t FEEL like an Integer’ and suddenly they are making ‘changes’ and you’re alone with the Xbox, a pound of bacon, and nothing but tears.

Floating Point Numbers

I’m talking numbers in Ruby right now, but I’m shaken to the core. Floating numbers are numbers! They should work right! They should ADD UP! Now, a floating point number is at least equal to itself. This passes:

assert_equal(0.1, 0.1)

But this doesn’t:

assert_not_equal(0.1, 0.4-0.3)

You’d think 0.1 == 0.1 but you’d be wrong! You see, 0.1 is only an approximation of the value stored by the floating point system in binary. 0.3 is an approximation, and 0.4 is an approximation. And when they are mathed, they don’t approximate out equally. There’s a loss of precision. It’s pretty close. This passes:

expected_float = 0.1
actual_float = 0.4-0.3
assert ( (expected_float - actual_float).abs <= 0.00000005 )

…it’s just not exact. It’s wrong over in C# too.

[Test]
public void FloatTests()
{
Assert.AreEqual(0.1f, 0.3f - 0.2f);
}

Goes boom:

Modulus

What’s a modulus? First off, I thought it was the number you get when you use the mod operator in a language…but it’s not. The modulus is actually the number you ‘divide’ by in a mod operation. The result is technically called the remainder.

Now the way I learned it, the mod operation is a lot like making change. If I have 1453 copper pieces (cp) and one silver piece (sp) is 100 coppers, then I find out how many silvers I have with simple division. This passes in C#:

int copper
= 1453;
int silver
= copper / 100;
int change
= copper % 100;
Assert.AreEqual(14, silver);
Assert.AreEqual(53, change);

And in Ruby:

copper = 1453
silver = copper / 100
change = copper % 100
assert_equal 14, silver
assert_equal 53, change

It’s all good so far, right? But what if I owe money? What if my initial total is –1453 ? I owe 14 silvers and 53 coppers, right? Well, yes. And that’s what C# shows. –14 silver and –53 coppers. But not Ruby:

copper = -1453
silver = copper / 100
change = copper % 100
assert_equal -15, silver
assert_equal 47, change

You owe 15 silver. And when you pay…you’ll get 47 copper back. If you want the C# (C++, C, etc) results, you’ll need to use positive numbers and handle the negative yourself.

I’ve been scratching my head around this, and it really seems like it’s an equally valid way of the numbers. The math people have both definitions lying around. And some cases have this method make more sense. Imagine you’re trying to find out what O’Clock it is. You have your hours variable and you use the mod operator. HOURS % 12. That works just fine, until you go negative. What if you wanted to know what O’Clock it was 143 hours ago? If it’s noon, and you’re using Ruby, –143 % 12 gives you the right answer.

I guess the accountants are right. “What do you want the numbers to be?”

A Testy Way of Learning Ruby

In my recent post, I started sharing some of the fun of learning Ruby using Test-Driven techniques to learn the language features and document what you are learning as you go.

There are several advantages of learning the language this way. It flexes your brain in ways that just reading the book or typing in the sample code doesn’t. Once you’re done, you have some running, organized code that you can refer back to. Also, when you upgrade your language, or change which platform you run it on, you can run your suite of learning tests. Find out if Ruby 1.9 is different from 1.8…and how. Are there implementation differences between linux Ruby and Iron Ruby? You’ll know.

Today, I’d like to cover the additional assert variants available in the Test::Unit module, and talk about using an IDE.

Last time, we covered the assert method for testing truth. But there are lot more things you can test!

  • assert – Tests the truth of an expression
  • assert_block – Tests that the return value of a code block is true
  • assert_equal – Tests that two values are equal
  • assert_in_delta – Tests two floats with tolerance for floating point error (read up on this one! it’s a doozy)
  • assert_instance_of – Tests that an object is an instance of a class
  • assert_kind_of – Tests that an object is of a class, or a subclass, or implements the kind
  • assert_match – Test using a regular expression
  • assert_nil – Tests the nil-ness of the expression
  • assert_no_match – A not test
  • assert_not_equal – A not test
  • assert_not_nil – A not test
  • assert_not_same – A not test
  • assert_nothing_raised – A not test
  • assert_nothing_thrown – Not a test. Just kidding.
  • assert_operator – I don’t get this one. Well, I’m still learning!
  • assert_raise – Tests that the code block raises a given exception
  • assert_respond_to – Tests that an object has a named method defined
  • assert_same – Tests that both values are the same object instance
  • assert_send – Another one to learn on. Looks like it tests a method call?
  • assert_throws – Looks like another type of exception handling.

With this group of methods, it should be rather easy for you to write some nice, readable tests as you learn things up. One interesting one is assert_same, which can prove that all values of True are really the same instance. Also, when you write a test that fails by raising an exception, use assert_raise to document that. You should have a test that shows what happens when you divide by zero, and one that shows what happens when you use an uninitialized variable.

Using an IDE

Most of the ‘True Ruby Folk’ believe with all their flinty hearts that you shouldn’t need anything more than a charred and pointed stick to write excellent Ruby. They are probably right. On the other hand, a good IDE can be like a coding video game and make the process so much more colorful and fun. I’ve sure found that JetBrains’ new RubyMine IDE has made my early Ruby coding a bit of clicky goodness.

Creating a new test class is really easy. You just add the file to your project:

You get a fully fleshed and voluptuous test class ready for you to have your way with it.

And while you’re learning the language, it’s really nice to have some code completion features so that you can figure out the rest of what you’re typing without going mad switching between windows.

All that and it’s not going to break the bank. Just $99! Give it a try.

I hope you’re keeping up with your test writing. I’ve got 168 assertions testing language features and I’m just through the primitives and variable types.

How many tests can you write?

Test-Driven Learning

You may not have realized it, but learning Ruby is like being attacked by a bunch of ADD Buddhist Monks. They’ll jump into your living room, raving and excited, and do back flips while telling you how Zen and relaxing development should be. It’s weird.

Once we’ve medicated the frenetic relaxation, though, it’s really evident that there a lot of good ideas to be found in this community. The latest that I’ve discovered is Test-Driven Learning.

What this means to me is that I can FINALLY stop writing ‘Hello World’ programs. Languages have print or printf or puts commands—we can stop being thrilled by that now. Ok? Let’s just write Tests! If we can make test Assertions, we can kick the tires of each new piece of language syntax we learn as we learn it without creating silly, baroque programs to host them.

Lets start out by discovering the shortest syntax to use the language’s testing framework. The one built into Ruby is Test::Unit. This is easy in Ruby. You need a ‘require’ line and to subclass the test fixture class.

require "test/unit"
class TestTest
< Test::Unit::TestCase
def test_tests
assert true
end
end

That’s easy. And now you can assert things. Like ‘true’. Save that in a file, like ‘test.rb’ then execute it with the ruby command line.

C:\Users\josh\Desktop> ruby test.rb
Loaded suite test_test
Started
.
Finished in 0.001
seconds.
 
1 tests, 1 assertions, 0 failures, 0 errors

From here on out, just start adding ‘assert’ lines as you discover things about Ruby. Since we started with ‘true’, maybe some asserts on Truth would be a good start. I wonder which of these will pass and which will fail? If you know Perl, Javascript, or C# your preconceptions will be different.

assert true
assert false
assert 'True'
assert ""
assert 0
assert 1

So little code, and now you can curl up with your favorite Ruby howto book and spend a warm afternoon pondering the nature of Truth. Exciting eh? Well calm down! You don’t need to be a crazy Zen guy. Just do some learning.

Resources: