Fresh.Thoughts

Testing async requests, mocking async methods with new Ivonna

Fri, 08 Mar 2013 00:00:00 GMT

For those of you who can't wait to start testing async requests, here's the good news (and no, there are no bad news in this post): starting with the 3.1 version of Ivonna, you can test them with the same syntax as before, i.e. using either session.Get(url) or session.GetPage(url).

However, this is not the end of the story. Most of the time you use the async pattern for a reason. You have a lengthy operation in your Web code. And that's the other good news: now you can mock async methods called from your controllers/codebehind/whetever, returning custom values. This functionality is a part of the Ivonna.Framework.MVC assembly, but you can use it with any Web framework -- it's not really related to MVC, but I didn't put it into Ivonna itself since I didn't want to introduce the .Net 4.0 dependency (this might change in the future).

Suppose you have the following code that you want to test (taken from MSDN):

public async Task<ActionResult> About() {
	var client = new HttpClient();
	string urlContents = await client.GetStringAsync("http://msdn.microsoft.com");
	return Content(urlContents);
}

You can test the whole method, but the test would have wait for the HttpClient to return the result, which can take a long time, and be unpredictable. In addition, you might want to test your controller's logic, not the code that runs the MSDN site. So, you want a predictable return value, and you want it fast. Here is how the new functionality helps you:

var session = new TestSession();
var fakeResponseString = "We Are Microsoft";
session.Stub<HttpClient>("GetStringAsync").ReturnFromAsync(fakeResponseString);

There's also a strongly typed lambda-based overload, but personally I find it less convenient and more noisy. Note that a stub like this works on all requests for all instances of HttpClient, so if you want a more fine grained control, you'll have to implement your own CThru aspect.

One more gotcha here. Some useful async methods are implemented as extensions, so you cannot use the syntax above. Use more verbose session.AddAspect(new Stub(..)) instead.

I really hope you'll find these new features useful. Enjoy!

P.S. I strongly suggest that you use this opportunity to save 16% on Ivonna and Isolator (ends March 31st).

Writing the first test for a Real System, Part II

Sat, 21 Jul 2012 00:00:00 GMT

Guilt. That's what I've been feeling all these days.

Ok, it's not that I spent the past month in a deep depression. I should confess that I'm not that kind of guy. But naming a post "blah blah part I" is kinda making a commitment. And the longer I kept postponing writing the second part, the worse I was feeling about it. So, I finally decide that I won't leave my workplace until I finish it.

In Part I, I have defined some guidelines that would help me in writing my first test. What's missing is the requirements for this particular system (Chpokk, and online C# code editor) I'm building. So, let me remind you these guidelines, this time with practical application.

I want to produce some business value as soon as possible

What I want my application to do is something that people will find actually useful. "As soon as possible" means a Minimal Viable Product from your marketing course. Perhaps it means that "at least one person might find it useful for at least a small something". In other words, it might be good for a demo. It is not big enough to be used in the daily life, but at least it's better than having just an AbstractFactoryFactoryAdapter. So, instead of building Version One piece by piece, I want to build Version 0.01, not caring much about clean and maintainable code (I'm postponing it for the Refactoring phase), but this version, although being far from perfect in all aspects, will actually solve someone's problem. And of course, among all problems that my applicationis going to solve, I'm choosing the most important one.

This is also very good in terms of getting user's feedback as soon as possible. Since I'm solving a real world problem, there must be some user out there who has this exact problem, so if I provide a solution (for free), this user is going to be my best friend, providing valuable feedback for the rest of her life.

Back to the point

So, since I'm building an online code editor, the "something useful" is, well, being able to edit the code. What means "edit"? It means, load, change, save. In my case, "load" is "clone a git repository", since that's where most of the code is stored today (yes I know there are other source control systems, and some people actually use the one named "file system", but I decided to start with Git), and display a file in the editor. "Edit" is "change a file in an online editor", which involves intellisense, refactoring, autosaving and whatnot, but let's forget about it until later. "Save" involves.. ok, let's not talk about it now.

This is the point where I'm going to contradict myself.

Theoretically, I should cover all three parts with one test. The problem is, that would involve multiple user interactions, meaning I should probably add UI testing (in which I'm not very proficient), meaning I should decide on UI (which I don't want to yet), meaning I'll still have to do a lot of things at once. Instead, I split my task into several smaller ones, but I'm not doing it from the developer perspective (I'm not test-driving specific classes), but rather based on user actions.

The first such action is cloning a remote repository. I agree that there is not much business value in it, so I'd rather not showing it to end users (except maybe for my 5-year old Alice), but still it's something that can be shown to somebody -- "hey, this thing can clone a repository!"

I don't want my tests to be fragile.

While I don't want certain parts to be fully implemented yet, I also don't want my tests to be dependent on them. These implementation details should be hidden from my tests, and never be tested themselves.

The main reason for a test to be fragile, meaning it can suddenly stop passing while the application behaves correctly, is that it depends on some implementation details. Whenever such a detail changes without affecting the application (for example, as a result of refactoring), the test breaks. Such a test brings more harm than benefit, since we cannot rely on it when checking our application's health. It becomes a burden -- we have to support it in addition to supporting our main application.

A typical example is an UI test that relies on element id's. If we are doing Asp.Net WebForms, we often let the framework generate these id's for us. As a result, each time we change our control structure without affecting its functionality (say, add a new NamingContainer), the id's (which are implementation details) change, and our test fails. Don't think that Asp.Net MVC is free from that -- a simple Action Method renaming would make a test that depends on it fail.

In our case, one of the implementation details is the physical location of the local repository. I can guess that I should do something to prevent different users or projects use the same folder, but I don't want to care about it right now. So, what I'm doing is encapsulating it, making sure it doesn't leak. For now, I hardcode it to a particular value, but I don't use this value in my tests. So, my tests, just as my production code, use this value without actually knowing it. Later, when the implementation changes, the tests won't break, since they rely on the same implementation.

It also allows me, as agile gurus advice, delay the implementation until it's really necessary.

The tests should not use any knowledge from outside.

This one has been covered a bit in the previous post, but I'd like to elaborate on it. Sometimes you look at the assert, and you don't understand it at all. I mean, it doesn't have to be crystal clear (that's what the name of the test is for), but at least I should be (eventually) able to understand it, because if it's broken, I have to fix it somehow. Whenever a test depends on some external resources, it becomes totally unclear. In addition, it encourages reusing this external resource, making it complex to satisfy the needs of all tests (I'm looking at you, a test repository for LibGit2Sharp).

Of course, this doesn't apply to the infrastructure. Even unit tests sometimes are better run with a real database, and we're talking integration tests here.

This is why, rather than taking a database that has some rows pre-inserted, I prefer taking a clean database and inserting the rows I need during the Arrange phase. Another example is when I need to parse a .sln file, rather than using an existing one, I'm creating it in the test. This way I'm free to create as many versions as I need for testing various cases, and I have a unique resource for each test, that contains only the stuff I need for this particular test. But the main benefit is that everything my test needs is just around the corner.

The requirements

Before we start writing our test, we should write down the requirements. As I keep insisting, our requirements shouldn't be developer-centric, i.e. they shouldn't be, like, "method xxx should return an instance of yyy with such and such property values". They should be formulated in terms of user expectations.

So, my task for today is to start implementing the "clone" story. I'm coming up with the following requirements:

When a user clicks the "open project" button, a popup appears that invites her to enter the repository Url (we assume that the repository is publicly readable). After entering an Url and clicking "Ok", the users sees a progress indicator.
After the process is finished, a user is redirected to the "Project" page.
This page should display the list of the files.

Now, as I mentioned previously, I'd like to split this into several tests. For a particular test that I'll be writing now, which is going to be entirely server-side, I've got the following story:

If a user submits the Url of a remote publicly readable repository to our system, it should clone a repository to a folder where this user can access it later.

Note that I don't specify the exact location of the target folder here (see Rule #2). Instead, there's a rather vague "where.. can access it later", which is not clear how to program. Let's say this means the result of some property or method which will be introduced by our code.

Finally, the code

I was delaying it as long as I could, but finally here it is:

using System;
using System.IO;
using Chpokk.Tests.GitHub.Infrastructure;
using ChpokkWeb.Features.Exploring;
using ChpokkWeb.Features.Remotes;
using LibGit2Sharp.Tests.TestHelpers;
using MbUnit.Framework;
using StructureMap;
 
// Namespace should correspond to the feature we're developing 
// Later it's going to help me to find this particular test
namespace Chpokk.Tests.Cloning {
	public class WhenYouSendACloneCommandToAServer {
		private string _fileName;
		private string _targetFolder;
 
		// First, prepare the context
		[FixtureSetUp]
		public void Setup() {
			const string repoUrl = "git://github.com/uluhonolulu/Chpokk-Scratchpad.git";
			// ARRANGE
 
			// Create a random filename
			_fileName = Guid.NewGuid().ToString();
			// Commit a new file to the remote repository
			var content = "stuff";
			Api.CommitFile(_fileName, content);
 
			// Prepare the target folder
			// This is where we get the relative repository path 
 			// See discussion about Rule #2
			var repositoryInfo = ObjectFactory.GetInstance<RepositoryInfo>();
			_targetFolder = Path.Combine(Path.GetFullPath(@".."), repositoryInfo.Path);
			// We cannot clone into a nonempty directory, so delete it
			if (Directory.Exists(_targetFolder))
				DirectoryHelper.DeleteDirectory(_targetFolder);
 
			// ACT
 
			// Get an instance of our controller.
			// I'm using a container so that I don't have to rewrite it
			// each time I change the signature of the constructor.
			// For unit tests, use automocking container.
			var controller = ObjectFactory.GetInstance<CloneController>();
			// Create a model for using with our Action Method.
			// PhysicalApplicationPath is databound automatically,
			// but in out test we need to submit it.
			var model = new CloneInputModel 
				{PhysicalApplicationPath = Path.GetFullPath(".."), 
					RepoUrl = repoUrl};
			// Finally, execute the Action method.
			controller.CloneRepository(model);
 
		}
 
		[Test]
		public void RepositoryFilesShouldAppearInTheDestinationFolder() {
			var expectedFile = Path.Combine(_targetFolder, _fileName);
			var existingFiles = Directory.GetFiles(_targetFolder);
			Assert.AreElementsEqual(new[] { expectedFile }, existingFiles);
			
		}
	}
 
}

Your posts are too long, and I don't understand the main idea

Ok, here's the summary:

1. Produce the business value as soon as possible. It means, identify the main benefit that your product does, and write a test for it, end to end. You are allowed, however, to split it into several tests, but each one should represent a significant feature.

Benefits: When you make this test green, you actually have a working product. You can receive an early feedback on it, you can show it to your Mom, but what's most important, it feels great!

2. Don't let the implementation details leak into your tests. It means, whenever you have to use some knowledge in your test that's irrelevant to the end user, hide it behind a piece of production code that's implemented as simple as possible.

Benefits: You don't have to think about these details right now and go straight to goal #1, plus, and this is actually the most important thing, you get solid tests. Because one of the main reasons that tests break over time is that the implementation details change, and these tests depend on them.

3. Always prepare your context in the test code. It means, other than infrastructure, everything that your test uses should be created as part of it.

Benefits: Such tests are much easier to support. If your test breaks, at least you can be sure it's not because some external resource has been changed. In addition, it is much easier to figure out what's going on in this test.

Wrapping up

This post (both parts) take too long to write. Probably much longer than it deserves. I think I should have written an ebook instead, sell it for $37, and become rich. Anyway, I hope it made somebody's life less boring.

Fixing the jQueryUI dialog height in IE, the Quirks way

Sat, 12 May 2012 00:00:00 GMT

Today I had some fun trying to figure out how to fix the height of the jQueryUI dialog. The client wanted it to be exactly 500px. Or something that resembled 500px. Anyway, it definitely shouldn't have been from the top to the bottom of the screen. Although I sure set it to 500.

The fun part is that it had to work in IE7-9, but in *quirks* mode. The client won't switch to the standards mode, since the site (made in early 2000's, tables inside tables all the way down) would break apart.

After some debugging, I figured that one line in a certain method would save me. Namely, a fix would require adding a line at the beginning of the "_size" method. So, I could just leave it like that..

Except that I couldn't.

Doing so wouldn't just violate the Open/Closed principle, it would offended the shadows of the Fathers of SOLIDity and the Alt.Net deities.

After all, JavaScript is a dynamic language, right? So, we can do whatever dirty trick we can think of, including messing with "private" methods.

Extending a jQueryUI Widget by rewriting a widget's private method? Nothing could be easier!

		var proto = $.ui.dialog.prototype;
		var _size = proto._size;
		proto._size = function(){ 
			this.element.hide(); 
			_size.apply(this); 
		};

While I could easily put there something like alert('OHMYGOSH!!!') (and have fun imagining my coworkers trying to figure out what's going on), what I'm actually doing here is just add something to the beginning. So, first I'm saving a reference to the existing function, then I redefine it, adding the line I need and then invoking the function itself.

So, why do I feel like I've just committed a sin?

A binder that breaks the rules

Fri, 11 May 2012 00:00:00 GMT

There are many binders in my big rusty toolchest. Some are good boys (and girls), others just like to misbehave. I mean, they do what they're destined for, and they do it really good, but in the process of doing it they break one or several Holy Laws that our Holy President wants us to abide by.

Nobody complains though.

This particular one saves me a lot of repetitive coding

Web requests tend to contain simple values. We developers like to work with objects. We like it so much that we are even willing to create objects from simple values. In particular, we often have to retrieve an object from the database (or from the cache), using its ID. Believe it or not, I was doing it at the beginning of almost every action method, sometimes two or three times. I felt so exausted that I would postpone writing the rest of the method until after a lunch break.

And then I saw the light

A few years ago Scott Hanselman wrote an article about an IPrincipal model binder (I use it a lot as well). And I thought, hey, these binders are not just for slapping your form values together, they can do more than that!

And I wrote the EntityBinder.

This particular binder may be frowned upon by respectable developers. Binders should know their place, you know. They are meant to stay somewhere between your M, V, and C. Your database and the business layer should be a forbidden territory for them.

Ok guys, you may have your controller full of boring repetitive code. I'm done with this.

Another Bad Thing that this boy (or is it a girl?) does, is that it does two things instead of one (what?? you forgot about the Single Responsibility principle???). It serves both as a custom binder attribute and a Binder. I did it this way because I wanted to save several keystrokes writing [EntityBinder("projectId")] instead of [EntityModelBinder(typeof(EntityBinder), "projectId")]. While one can argue that the code for the binder became less maintainable, the code that used it became twice as maintainable, and that was a huge gain.

The downside is that I couldn't use Dependency Injection in that binder (at the time of the writing, I couldn't use it anyway, because it was the first version of Asp.Net MVC), so I had to resort to Service Location (and had never had any problem with that).

What exactly this shiny binder does, anyway?

The binder that I'm going to show you looks at the parameter name and type and tries to guess the name of the field that holds the ID, and the type of the entity. So, given a declaration like this:

public ActionResult AnketaDefinition([EntityBinder] Project project)

it looks first for a request value named "projectId", and if it cannot find it, for a value named "Id". Then it asks the ORM for an entity of the type Project with that Id.

In case we don't want the defaults, we can provide our own, but it happens very rarely.

There is one question though. What do we do if we don't find the id in the request? It turns out that there are cases when we want to return null, and cases when we want to throw an exception. There is an additional boolean parameter called "relaxed" which you can use for that. What is default behavior, you decide. I'd recommend throwing an exception, just in case.

And finally the code that you can steal use

The code together with a sample aplication can be found at GitHub. The main part, however, is below:

public object BindModel(ControllerContext controllerContext, ModelBindingContext bindingContext) {
	var fieldName = bindingContext.ModelName + "Id";
	var result = bindingContext.ValueProvider.GetValue(fieldName);
	if (FieldNotFoundOrValueIsEmpty(result))
		fieldName = _idName;
		result = bindingContext.ValueProvider.GetValue(fieldName);
	if (FieldNotFoundOrValueIsEmpty(result)) {
		if (_relaxed) return null;
		throw new MissingFieldException("Could not find the request parameter: " + fieldName);
	}
	var entityType = _entityType ?? bindingContext.ModelType;
	var session = ObjectFactory.GetInstance<ISession>();
	var id = GetId(result, fieldName);
	object instance = session.Get(entityType, id);
	if (instance == null)
		bindingContext.ModelState.AddModelError("null", 
			new HttpException(404, 
				string.Format("Could not find {0} ({1}: {2}", entityType, fieldName, id)));
	return instance;

}

First I look for the field value using the rules I mentioned above. Next, I figure the entity type. If not specifically set in the attribute, the type should be that of the parameter we're binding to. Next, I use StructureMap.ObjectFactory to get an instance of NHibernate.ISession. You can use any container and ORM you like. The rest is simple. I have omitted the part where you handle array valued parameters, you can see it in the original source.

Writing a test for our great binder

As always, I prefer writing an integration test, the one that actully executes an Asp.Net request, because it lets me demonstrate how powerful Ivonna, my Asp.Net testing tool, is. This time, however, I'm adding a little bit of mocking (so it's not a 100% integration test). Because I don't want to setup NHibernate with all that mapping, bootstrapping, and stuff, I'm just stubbing the DB access using the new Ivonna/CThru Stub syntax:

session.Stub<ISession>("Get").Return(entity);

Here you have some kinda brute force stubbing, where you don't need much flexibility, and you don't want anything "force" you into a supposedly good design (which is close to impossible when writing integration tests anyway). Just make the Get method on any ISession instance return this object, regardless of the arguments (strictly speaking, we should verify that the argument is as intended, but let's not overcomplicate our test). Here is the full test:

var entity = new Entity();
// We don't want to set up an ORM, 
// so we'll just fake ISession
var session = new TestSession();
session.Stub<ISession>("Get").Return(entity);
 
// Now let's execute a Web request
var response = session.Get("/Sample/Get?entityId=1");
 
// Check the result
Assert.AreEqual(entity, response.ActionMethodParameters["entity"]);

As you see, we prepare an Entity instance, have it returned from the stubbed ORM call, then execute our request, and verify the parameter of the action call. Our Web should have the SampleController class with the Get method having the following signature:

public ActionResult Get([EntityBinder()] Entity entity)

That's it for today, I do hope you'll find it useful, and please tell me that you like to break the rules as much as I do, whenever it makes your (and the others') life happier. I do believe that releasing this binder to the general public I'm doing a Good Thing, and the world became a better place because of this, and maybe even a couple of whales will be saved from brutal killing, but maybe not.

Configuring your assets for FubuMVC

Sat, 14 Apr 2012 00:00:00 GMT

When you have a complicated View, things can easily get messy. A View may have several Partials, each Partial being reused in several Views. Each Partial might require certain library scripts, which in turn might depend on other scripts.

(At this point, I stopped and thought, maybe I should really add images to my posts. Ayende does it, although he has clearly no time for finding an appropriate image. All the cool guys do it. Perhaps I should do it, too.)

(By the way, if you know a place where I could quickly steal images for my posts, please tell me in the comments. I heard that it makes them more entertaining and gives a personal touch.)

Turned out FubuMVC provides a nice solution to this problem. You can have an arbitrary number of "config" files (the extension is misleading, they're plain text files) in arbitrary places, named either *.script.config, or *.asset.config. Each file describes relationships between assets, or just groups them for reference. After that, your View just references a file it needs, and your Master issues a directive to render all required files.

How do you write a config file

If you have scripts dependent on each other, you need an ordered set:

ordered set {set name}
{name1}
{name2}

For example,

ordered set jslib is
lib/jquery-1.7.1.js
lib/jquery-ui.js
lib/bootstrap.js
lib/tree.jquery.js
lib/amplify.js

Unordered set:

{set name} includes {name1}, {name2},..

Individual dependencies:

{asset name} requires {name1}, {name2}

For example,

demo.js requires jslib

Ordering individual files:

{asset name} preceeds {another name}

Applying a custom policy (should be a type implementing either IAssetPolicy or ICombinationPolicy):

apply policy {policy type}

Combining assets:

combine {name1}, {name2},.. as {set name}

Alias:

{alias} is {asset name}
e.g., jquery is lib/jquery.min.js

Extending (not sure what it means -- please enlighten me!):

{asset name} extends {another name}

In addition, you can have empty lines for readability, and lines starting with '#' for comments.

How works them config files?

Suppose you have the pieces provided above in one of your config files. Whenever you need the demo.js script on your page, you just put

<Script src="demo.js" />

somewhere close to the top of your View (assuming you use a Spark ViewEngine with the default bindings; it would work for other Views, of course, but with a slightly different syntax). This directive doesn't output anything, but it tells the Asset Pipeline that you'll need that script at some time. Later, presumably in your Master, you have the following:

<Scripts />

This should render all the required scripts for the page. In particular, although we have never mentioned we need jQuery, it's going to be referenced, since demo.js needs it. All scripts will be rendered in the correct order. In addition, there won't be any duplicates.

Another Good Thing is that the config files acan be easily reused across different projects. After all, the library dependencies is what doesn't depend on a particular project.

This can't be so good. Now tell me the bad news!

The bad news is that the current implementation enforces rather strict rules for where your assets should be. Namely, everything should be placed in the Content folder, with the hardcoded subfolder names for styles, scripts, and images. this doesn't work good with styles requiring images in a subfolder, and also can cause some friction e.g. when updating jQuery via NuGet. While having such a rigid structure is a bit unusual for this otherwise very flexible framework, the benefits, in my opinion, outweight the (forgot the English word for that thing that is outweighted by the benefits).

For a real-world sample of what I'm talking about, take a look at https://github.com/DarthFubuMVC/fubumvc/blob/master/src/FubuMVC.Diagnostics/diagnostics.script.config

Writing the first test for a Real System

Sun, 11 Mar 2012 00:00:00 GMT

So, you've read a book on TDD, a couple of blog posts from the gurus, and maybe even done the Calculator Kata several times. Now it's time to apply your knowledge to a Real Life Project that you are starting today. You probably stare at the empty solution and try to figure out where to start. "Create an instance of the System Under Test".. which system? "Mock or stub the dependencies".. which dependencies?

Sounds familiar?

Let me give you a hand

Right now I'm also staring at the (almost) empty solution. I'll try to document what I think and do, and maybe you'll find it useful. However, remember that it's not the only way to do it, it's probably not the best way, and it even might be a bad way. But it works for me, and it might work for you, so, if you don't have a better solution, you might wanna try this one..

Meet Chpokk, an online .Net code editor.

Chpokk is meant as a lightweight replacement for Visual Studio, integrated with source control, plus some goodies like refactoring support, running your tests etc. I decided that today is a great day to develop the first feature that might be actually useful.

What do I want from my tests

There are several important requirements, that will help me a lot in writing my first test.

I want to produce some business value as soon as possible. I don't have time for all these funny AbstractFactoryFactory toys. If that means creating a one big static method, fine. I'll refactor it later. But when I refactor it, I need it to be covered with a test. So, my first test should be about the first useful thing I want to implement in my system.

I don't want my tests to be fragile. I don't know what my UI is going to be, and I don't know my API yet. But changing the UI can easily break many tests that depend on it, while the server side code can be easily refactored in sync with the tests. Not just UI, anything "stringy" should be kept out. For example, I don't want to hardcode the folder in which I'm going to keep the user's code files.

This requirement kind of contradicts the previous one, which suggested that my first test should cover everything. But while the first rquirement is more like a nice wish that would make me happy right now, the second one would save me from perpetual pain later, since robust tests are what makes me sleep well at night.

The tests should not use any knowledge from outside. This is better explained with an example. Say, I'm going to clone an existing repository from GitHub. Then I'm going to check if a certain file exists locally. The knowledge about the name of the file that should be there is not a part of the test. This can be a problem, since later looking at this test I won't know why it expects this particular file. In addition, I might rename this file later in order to use it in a different test.

How can I fix it? By adding this file to the remote repository as a part of the test. That makes my life harder, but at least I can look at the test and understand why the file should be there. In addition, my test is responsible for setting up its environment. Ideally, the test should have created a remote repository, of course, but that's probably too much. In fact, perhaps I could even manage without adding this file, but the repository content is a changing thing, while the repositories themselves tend to stay longer.

Enough philosophy, show me the code already!

Not so fassst, mah friend! Just wait for the next part, where I'm figuring the requirements for the first iteration and writing tests for them.

Ripple, the utility that saves you from your personal NuGet hell

Fri, 02 Mar 2012 00:00:00 GMT

Managing your dependencies with NuGet can be just fine.

Unless you want some of these be compiled locally.

For example, imagine that you have a complicated dependency graph, and you've just modified a source of one of the assemblies. Or you just want the freshest bits from the source control. Now you want to use the local version in your project, since you don't want to wait till your modification is accepted and released as a NuGet package. At the same time, you want to use the other dependencies managed for you by NuGet, plus merge the recent updates to the ones that you build locally. Welcome back to dependency nightmares.

This could be even worse than the pre-NuGet era. If only Ripple didn't exist.

Ripple was created for scenarios like this. Well, not exactly, but at least it can save you from Dependency Hell. What's even better, Ripple will do a lot of things for you so that all your solutions will have the freshest bits from NuGet when the local source is missing, and locally built assemblies conveniently put into the NuGet package folders.

In other words, Ripple is NuGet's best friend.

For a good introduction to Ripple (and its requirements), check the Ian Battersby's Ripple-tastic! post. Ian gives an example of a "targeted" rippling -- from one to another solution. However, I have discovered it's more fun to just "ripple around" -- shoot "ripple local" without the "from" and "to" pieces. This way Ripple just fixes and updates everything it can.

There are many Ripple commands available. Here is the (incomplete) list of them, as of today.

Clean -- just clean a particular solution, or all solutions. Can clean packages, project outputs, or both.
Float -- makes the package "floating" -- marked as to be updated by Ripple.
GitIgnore -- Lists or adds values to the .gitignore file.
History -- write the list of packages to the dependency-history.txt file.
Init -- Creates a basic ripple.config file and opens it in an editor, removes packages from Git and adds their folder to .gitignore
List -- for each solution, outputs the list of projects with their dependencies and published packages.
Local -- you better try it yourself with a verbose flag and watch the output.
LocalNuget -- Creates the nuget files locally
Lock -- opposite to Float, locks a nuget to prevent it from being automatically updated from the Update command.
Publish -- Builds and pushes all the nuspec files for a solution(s) to nuget.org.
Restore -- another important command, interacts with nuget to restore all the nuget dependencies in a solution tree.
Update -- gets the latest NuGets (or just lets you preview them). As I understand, either Restore or Update is used as part of the Local command execution.
UseTheirs -- Does a 'use theirs' merge on all the project and packages file in a solution.
WhereAmI -- Tells you where ripple thinks the root folder is at.

You can see that this is a great piece of functionality for those who works actively with OSS dependencies. It is opinionated, in the ForUsByUs way, but you can happily use it in non-Fubu projects. The only annoying limitation for me is that you should keep your projects in the same folder, but it's not annoying enough for a pull request.

Ripple is included in the buildsupport submodule if you get the source of any Fubu project.

Getting started with Jasmine tests in FubuMVC applications

Sun, 19 Feb 2012 00:00:00 GMT

Jasmine is one of the most popular BDD-style Javascript testing frameworks. I decided to use it for my new project, Chpokk, built on top of FubuMVC. Here are the steps that I made, together with some for-dummies explanations.

Adding Jasmine to your project

is as easy as adding the FubuMVC.TestRunner NuGet package to your project. After that, navigate to /testing/suites/whatever, and see a greenish almost empty page that says "0 specs". Jasmine is installed.

What's under the hood?

After you add the package, you discover a zip file named fubumvc-testrunner.zip in your fubu-content folder. This file is a "bottle", a piece of functionality that adds itself to the main application. With the first Web request, the zip is extracted ("exploded") to a subfolder. Let's see what we have there.

The WebContent folder is mapped to the root of your application. The Shared subfolder contains the Application.spark file, which is going to be the master page for all test pages, and the bindings file.

Take a look at the following snippet from the Application.spark file:

	<Stylesheet href="jasmine.css" />
	<Script src="fubumvc-testrunner" />

These tags look unfamiliar. Their meaning is explained in the bindings file:

  <element name="Stylesheet">#this.Asset('@href');element>
  <element name="Script">#this.Asset('@src');element>

this.Asset() is a method that adds a script/css to the list of assets of the page. Note that it produces no output; in order to write all scripts (together with their dependencies), you have to call

this.WriteScriptTags()

or, using our bindings, just

<Scripts />

The actual View is called Run.spark, and located in the suites folder. It's very simple:

<viewdata model="FubuMVC.TestRunner.Suites.RunSuiteViewModel" />
<content:title>${Model.Suite}content:title>
<content:scripts>
  <Script src="${Model.Suite}" />
content:scripts>

There are two content areas: one is the page title, the other just adds a script (or a set of scripts, see later) to the page. How do we decide which script to add? We take it from the Url. Because of some model binding magic (plus internal Fubu processing), the last part of the Url is mapped to the Suite property of the model.

Adding the first test

In order to use the Fubu's Asset Pipeline, I put my test script into the /Content/scripts folder of my Web.

Here is my sampletest.js:

describe("First test", function() {
	it("should fail", function() {
		expect(true).toBeFalsy();
	});
});

As a real TDD practitioner, I'm creating a failing test first. Mom would be proud of me!

After saving this file, I navigate to /testing/suites/sampletest.js, and I see a failing test. WIN!

Dealing with a Real World Problem

Having all your code in the tests is fine, but at some point a manager might want you to move some of it to the production files. So, we'll need to include several files in our tests. Let's see how to do it.

Let's create another file called realstuff.js, and put it into the Content/Scripts folder:

function arewegood() {
	return false;
}

Next, let's create a plain text file, named tests.script.config, and place it in the root of our application. This file will hold our script set definitions. Right now, we'll put the following line there:

tests includes realstuff.js, sampletest.js

Now, we'll use the name of the set in the Url: /testing/suites/tests. If we look at the source, we'll see that both scripts are loaded. We can put another script set in our config file, and we'll be able to run a different suite with a different Url.

The last step is to modify our test so that it depends on the "production" code:

describe("First test", function() {
	it("should fail", function() {
		expect(arewegood()).toBeTruthy();
	});
});

That's it for today, I still have to make this test pass.

Update

@jmarnold pointed me that Serenity does all that and lots of other great stuff. I guess I'll have to delete all this and start from scratch. In the next post, I'll tell you what happened.

Custom Asp.Net Model Binders series, part 3: Subclassing your models

Thu, 02 Feb 2012 00:00:00 GMT

This is the third part in the series about custom Asp.Net MVC Model Binders and Value Providers. Part 1 is about two ways of using DateTime.Now as an Action Method parameter for better testability, and Part 2 is about building a Value Provider for the Http Header values. Read on.

What's up with subclassing your models

Often you need to use inheritance in your domain model. For example, you might have to model a book with a list bibliographic references. Each reference might be to an article in a magazine, to another book, to a Web page etc. So, you create a Reference abstract class, and a couple of subclasses for different types of references. You might also want to create a parallel inheritance chain for your models.

Now, suppose you have a list of references. Each row has a link to the page where you can edit the corresponding reference object. While different types of references have different fields to edit, you don't want to create a separate page for each type. Displaying a reference is simple: you just call Html.EditorFor() inside your form, and the fairies will generate the necessary fields for that particular kind of reference. The problem is how to get the new values back.

Suppose you have the following action method:

[HttpPost]
public ActionResult Update(ReferenceModel model) {
	//...
}

The default binder will try to create an instance of ReferenceModel, and will fail, since this is an abstract class. So, we'll have to use a different binder. The one that is smart enough so that it could create an instance of the concrete type.

Implementing the SubclassingBinder

In order to do it, we'll have to provide the name of the model's type. We'll do it via a hidden field called ModelType:

<input type="hidden" name="ModelType" value="<%=this.Model.GetType() %>"/>

One would be tempted to override the CreateModel method, but that wouldn't be enough. The model would be created, but it would not be populated with the subclass-specific properties. The binder would still use the metadata of the base abstract class, so the properties specific to the concrete class will not be picked up.

So, we're going to override the BindModel method and "correct" the model type, then let the binder create and bind a model of the requested type for us. Here's the code:

public override object BindModel(ControllerContext controllerContext, 
	ModelBindingContext bindingContext) {
	if (bindingContext.ValueProvider.ContainsPrefix("ModelType")) {
		//get the model type
		var typeName = (string) bindingContext
			.ValueProvider
			.GetValue("ModelType")
			.ConvertTo(typeof(string));
		var modelType = Type.GetType(typeName);
 
		//tell the binder to use it
		bindingContext.ModelMetadata = 
			ModelMetadataProviders
			.Current
			.GetMetadataForType(null, modelType);
	}
	return base.BindModel(controllerContext, bindingContext);
}

Do you have teh tests?

Oh yes we have! As always, we're going to test our code with the help of Ivonna, our favorite Asp.Net testing tool. Here's the test. It verifies two things: given the model type and a property value, a model of the correct type is created and the property is filled with that value (disclaimer: I'm usually opposed to several asserts in a test, but I'm doing it here for clarity):

[TestFixture, RunOnWeb]
public class ModelSubclassing {
	private const string NEW_ARTICLE_NAME 
		= "On the meaning of death";
 
	[Test]
	public void BinderCreatesArticleModelWithValues() {
		var response = new TestSession()
			.Post("/Sample/UpdateReference",
			new {
				ModelType = typeof(ArticleModel)
					.ToString(),
				ArticleName = NEW_ARTICLE_NAME
			});
			
		//verify that we have the corect model type
		Assert.IsInstanceOf<ArticleModel>(
			response.ActionMethodParameters["model"]);
		//verify that we have filled 
		//the concrete type specific properties
		var model = 
			(ArticleModel)response
				.ActionMethodParameters["model"];
		Assert.AreEqual(NEW_ARTICLE_NAME, model.ArticleName);
	}
}

That's all for today. You can grab the code from GitHub. Comments are welcome!

A useless custom Asp.Net value provider (or maybe not that useless after all)

Wed, 07 Dec 2011 00:00:00 GMT

So, following my previous post on implementing a custom Asp.Net Value Provider, here is another one.

Request Header Value Provider

Here is a totally useless requirement: add a Value Provider that would let you use your request headers in your actions without calling HttpContext.Current.Request (or something equally unacceptable). This is actually absurdly simple, because we already have a convenient base class, NameValueCollectionValueProvider, that takes a collection and provides its values to the unsuspecting Controller. So, the code it pretty simple:

public class RequestHeaderValueProvider : NameValueCollectionValueProvider {
	public RequestHeaderValueProvider(ControllerContext controllerContext)
		: base(controllerContext.HttpContext.Request.Headers, 
			CultureInfo.CurrentCulture) { }
 
}
 
public class RequestHeaderValueProviderFactory : ValueProviderFactory {
	public override IValueProvider GetValueProvider
			(ControllerContext controllerContext) {
		return new RequestHeaderValueProvider(controllerContext);
	}
}

Note that we need a ValueProviderFactory again. And we need to regiser it in Global.asax as well:

ValueProviderFactories.Factories.Add(new RequestHeaderValueProviderFactory());

Now it's enough to name the action method parameter as the header you need, and you'll get the value automatically.

Writing a test for it

So, I wasn't completely honest with you when I said it was completely useless. Apart from using it in RESTful apps, there is a pretty common need to get the Referer value, mostly for redirecting back to it as part of the Post-Redirect-Get routine. So, we can test two things (using Ivonna of course): that we have our Referer value as an argument, and that we are actually redirecting to it. Both are integration tests, and the second one is testing both our infrastructure and the actual Action method, but who cares:

[Test]
public void TestHeaderProvider() {
	var request = new WebRequest("/Sample/ActionUsingReferer")
		{AutoRedirect = false};
	const string previousurl = "/PreviousUrl";
	request.Headers["Referer"] = previousurl;
	var response = new TestSession().ProcessRequest(request);
	Assert.AreEqual(previousurl, 
			response.ActionMethodParameters["referer"]);
	Assert.AreEqual(previousurl, 
			response.RedirectLocation);
}

Notice that we have to disable the Autoredirection feature of Ivonna: without that, we'll be testing the result of the redirection (quick poll: do you want this property to be false by default?), rather than the original request. Notice that we ae using the new MVC feature of Ivonna: the ability to get the action method parameters.

Finally, here's the code that makes this test happy:

public ActionResult ActionUsingReferer(string referer) {
	return Redirect(referer);
}

Unfortunately, header names like User-Agent are not very C# friendly, so you might have modify your code in order to be able to consume these headers as parameters named, say, user_agent.