I was playing around with using extension methods within my mspec tests and think I have found a nice way of descriptively setting up variables:

I am not too sure about the scanability of the tests since it requires a bit of jumping around to find out what is going on however I do like that the test is more English than C#

Every once in a while a new evolution of tools comes along which makes the development of software substantially easier, simpler and funner. This happened with WPF, Monorail/ASP.NET MVC, Moq, OpenRasta and now MSpec. I’m not one for hyperbole but I think that MSpec has significantly improved the quality, readability and maintainability of my tests.

There are a lot of articles about how to get started with MSpec so there is little point writing yet-another-beginners-guide-to-mspec. Instead I thought I would share my best practices and general thoughts about MSpec. Much of this is just a re-iteration of points that Aaron has made on various places but has not been put into a central place.

Core philosophies of MSpec

• Simple If you look at a lot of NUnit style tests, they are often incredibly complex and difficult to understand. I often have to read through lots of setups, methods, etc just to understand what is going on. You should strive to keep things as simple as physically possible. Ideally you should never have to navigate around away from the current spec to understand what is going on.
• Scannability You should be able to easily scan a spec and understand what is going on. Everything that is happening in the spec should be clear to the developer so when they come to maintain the class they can worry about writing more specs rather than figuring out how to add them.
• Anti-syntax MSpec tries as hard as possible to stop you from writing C#. In fact pretty much the only bit of C# you have to know is the () => (or as SerialSeb calls it, the penis operator). This allows you to concentrate on describing the behaviours you want the system under test to exhibit rather than writing C#.
• Best practices The syntax for MSpec forces you into using best practices e.g. by using lambdas, you often find yourself wanting to write single line assertations thus only testing a single thing at a time. Also, it has the whole arrange, act, assert pattern embedded in via the Establish, Because, It keywords (although this is common amongst all BDD frameworks. By making it harder to do things the wrong way, it is less prone to abuse and so even novice developers tend to write better tests.

Base class best practices

The old school Mspec way to write specs was to encapsulate states in base classes, e.g. class When_a_users_email_is_invalid : with_an_invalid_email {}. This makes it harder to scan the spec and understand what is going on so this pattern has been discouraged by Aaron. Instead he suggestsyou should ideally have no base class whatsoever if the state you are testing is simple enough to be formed with a couple of lines. This is a pattern you should strive for but often there are a significant number of specs which all share some common variables, set up and events. When this is the case it is advisable to create a base class which contains any common set up (Aaron gives an example) with the name {ClassUnderTest}Context/Spec (We use context whereas Aaron uses Spec, this is down to personal choice).

The context should contain common objects that the class under test depends on and put them into the state the specification requires them to be in. If these objects need to be accessed via a subclass then expose them via a protected static field (note, not a property; they add unnecessary clutter).

The context should never contain a Because. Even if every single spec used the same same event it is still important for readability to have the actual event explicitly stated in the spec. I also found that when I put the Because in the context, when coming back to maintain the tests I would often want to test a different event meaning I would have to refractor all the existing specs. While I say that you must explicitly state the Because in each spec, the actual implementation can reside in the context. I find myself often using this pattern:

Establish best practices

The Establish keyword (i.e. the Given in other BDD frameworks) is the “arrange” in the “arrange, act assert” pattern. Knowing this, you must ensure that the only thing that you place in the Establish is code which for establishing the specific state of the system under test which is required for the expected behaviour defined by the specification. Although wisdom states that code in the Because/It should be terse (ideally one liners) within the Because there are no such restrictions. In complex scenarios the Because can often contain 5-10 LOC. Thankfully (like all keywords) they are inheritable and so you can move common set up into a base context with the order of execution going down the inheritance chain (i.e. base class first, spec last)

Because best practices

The code within the Because (i.e. the When/act) method should contain the event which causes the behaviour we are requiring e.g. invocation of a method/event. One issue I often see is people setting variables within the Because, unless setting that variable causes the event under test to occur (i.e. if it is a property with logic in the code behind) then that code should go in the Establish since it is establishing the state of the system under test and not causing the behaviour to actually occur. I would go as far as saying you should only allow invocation of methods/events/properties with logic in backing fields within your Because statement. Another further smell is when the Because statement is more than 1-2 lines. If this is the case, your are probably testing too many things at once and should re-evaluate the scope of the specification and/or refactor the system under test.

With regards to handling exceptions caused by an event, the advice on the MSpec GitHub page says that you should catch all exceptions and then handle each case individually. e.g.

However, unless you specifically state that the system under test should not throw an exception (e.g. It should_not_throw_an_exception = () => Exception.ShouldBeNull()) it often leads to the system throwing exceptions without you knowing. The intermediary solution to this has been to add a boolean to state whether we are expecting an exception in the spec e.g.

Personally I think this is pretty ugly and so I have been playing around on my fork of MSpec with this syntax:

Essentially the Expecting.Exception() method would tell the runner to catch any exceptions thrown from the Because action and place it in the Thrown.Exception property. What do you think? I would love some feedback on this syntax.

It best practices

The It’s (i.e. the Then/Assert) are where you describe the desired behaviour of the system under test. The name should be a descriptive sentence of a single desired behaviour you want to occur when the system is in the state established by the Establish and the event that occurred in the Because. The actual code for each It should only contain assertions, e.g. Exception.ShouldBeOfType(), Result.ShouldEqual(1), etc. It should not contain any other forms of code, e.g. clean up code/further events. Ideally each It should be a one liner since you should only be testing one thing at once. There are exceptions to this rule, however, if you find this becomes the norm then you should reconsider how much you testing at any one time.

General Best Practices

• If you are testing a class always add the subject (e.g. [Subject(typepof(ClassUnderTest))]) to the top of your spec. It just makes life *so* much easier when you want to navigate to the class under test.
• Don’t use Behaves_Like. It massively reduces the scannability of a spec, requiring you to jump around classes to understand what is going on. The creator of MSpec even considered removing it because it contradicts the one of the core design goals of MSpec. DRY in tests is not nearly as important as comprehension.

Other thoughts

• Anyone who has used MSpec with Moq will probably question why the keywords Establish, Because & It were used over Given, When, Then. Although I personally don’t know myself I am assuming there is wisdom behind the madness. That said I think support for both set’s of keywords would defiantly make life easier for people using these combination of tools. It is something I have added to my fork of MSpec and have found it makes life significantly easier (I actually stole the idea from Gary Shutler)
• There are a lot of really good ancillary tools being built to support MSpec (e.g. Machine.Specifications.AutoMocking, Machine.Specifications.MVC). I am really excited about how the community around this tool is growing and is really good sign for the project. I would thoroughly recommend people both check out these projects and also see what else is missing!

As I said at the beginning most of what I have said is not new and some is most probably wrong. However I have found that the current documentation is a little lacking (although it has recently improved) and so I thought it would be good to consolidate it into one place. These are only my thoughts about how you should use MSpec so I would love to hear what other people have to say about it.

As Huddle grows we start to see more and more of the edge cases of the world. One bug I had to fix to our email regexp so that it would support single letter domains. Up until now we have been using Haaked’s regex which has been us well however it doesn’t validate single letter domains so we needed a better solution.

The solution was pretty stupidly simple actually, the .net framework already supports email validation!

try
{
   new MailAddress("foo@huddle.net");
   return true;
catch
{
   return false;
}

I’m not certain why but for a while now I’ve really wanted to write a sort of python/ruby-esque DSL on top of ASP.NET MVC. I am probably going a little crazy and this is a dumb idea but I thought I might as well write it down and get it out of my system.

It would look something like this:

controller User:
   //Actions are composed of method + name

   get Add:

      pass

   post Add(userInputModel):

       (homeInputModel -> User).save

       redirect controller:home, view:foo

//Automatic transformation of types (e.g. view model -> domain object)

transformation HomeInputModel -> User:

   HomeInputModel.Name <=> User.Name

   HomeInputModel.Email <=> User.Email

   HomeInputModel.Password <=> User.Password

//Validation of domain objects before they are persisted

validate User:

   //Basic boolean validation logic

   Name.Length > 0

   //More complex business logic requiring a code block

   Name n:

       if n.First() == ‘y’:

           ValidationException “We don’t like people who’s name starts with y”

model User:

   string Name

   email Email //Built in type’s for common forms of data, e.g. emails, passwords. Enables default validation

   password Password

   Many<Task> Tasks //Complex db relationships inbuilt

Underneath this would all compile to C# or IronPython using NHibernate & Asp.net mvc with various custom bits inbuilt. What do you think, am I going a little crazy?

I needed to programamatically add a log4net appender at runtime, the docs for all of this are all a little fuzzy so just for future reference

class FileCleanerAppender : RollingFileAppender

{

public FileCleanerAppender()

{

File = "Foo.log";

AppendToFile = false;

RollingStyle = RollingMode.Once;

LockingModel = new MinimalLock();

Name = "SomeAppender";

Layout = new PatternLayout { ConversionPattern = "%m" };

ActivateOptions();

}

}

((log4net.Repository.Hierarchy.Logger)LogManager.GetLogger("SomeLogger").Logger)

.AddAppender(new FileCleanerAppender());

I recently read Ian Cooper’s blog regarding the current state of Alt.net. There has (in my opinion at least) been a growing sense of disillusionment within the alt.net community of late and Ian has given some good arguments for some of the most common complaints. I completely agree with him on the points he made, Alt.net was and still remains to be an incredibly important part of the .net community. The principles that David Laribee laid out have had a massive impact on the .net landscape; use of alternative languages is common place (Rake seems thankfully to be replacing NAnt), everyone knows how much money and time TDD will save (i’ve got a little bit of addiction for that green light) and the owners of JetBrains will be happy to hear that any dev worth his salt knows the R# was written by god himself.

My issues with alt.net arises from the fact that we seem to talk about the same things over and over and over and over again. I get it, IoC, ReST and TDD are all awesome but you are preaching to the converted! Yes, there are many people out there that have never used these tools and do not understand their benefits. Unfortunately very few (if any) of those people actually come to these events because they just don’t care that much about it. I understand that this is a battle some people want to fight but not me, I’m more interested in writing code. Personally I feel we must accept that people who actually give a damn about code are in the minority and move on to much more interesting things.

What about new members to the alt.net community you might ask? From people I have spoken to, the learning curve to entering the Alt.net community is actually quite high. There is also a degree of elitism; try telling an alt.net’er you don’t know what IoC is and enjoy the look of horror on their face. We need to lower the barrier to entering the community and make a more active effort to include new members who are genuinely interested in writing good code. You never know they could build the best thing since sliced MVC.

London is very lucky to have lots of people doing free talks tools that they have created/played with (many thanks to skillsmatter for helping organising them). These talks are really important in helping exposing developers to new technologies but what about ideas/skills which are difficult to distill into a 30min talk e.g. how to create a well architected app? what’s the best way to test a legacy app? These sort of practical skills are ultimately much more important than using some new technology yet there seems to little available knowledge. If people are genuinely interested in helping to build a better .net community then I feel we need to stop talking about the alt.net principles and start looking at how we can apply them to actual problems.

Alt.net has produced all these great ideas which people have taken on board and gone off and built some really cool things. I think we need to start sharing what we have learnt in a format which encourages sharing of practical knowledge between developers.

So what am I proposing? Put simply I think we should have a way for people to publish problems/ideas they have which that require a technical implementation. These ideas can be anything really (e.g. a game, problem at work, etc). Ideally though they should be something which is a bit of fun (we spend all day at work doing boring dev work, this should be about having fun writing code). If other people are interested in the idea then you can work together (whether in the same place or remotely) on the project. If there are specific skills that you dont have but need then you should be able to contact the community and find a specialist (e.g. solr, BDD) who can give you some guidance. Every month we can all meet up and demo our projects (similar to what Y. Combinator does). This gives us a chance to get together, discuss our problems & solutions and get some advice from other devs (oh and a good excuse for a drink).

I think if we concentrate more on writing actual code to solve fun problems, using the alt.net principles and community to help build the best solution, then we would all greatly benifit. What do you think? Would love to hear your thoughts!

James

A major problem I’ve found at huddle was what a pain in the arse configuring IoC using xml is! So instead of moaning about it I decided to write a new library called FluentIoC to make my life a bit easier.

The main aim’s of the project were

• Not use any xml
• Make it easy to configure and use IoC
• Easy to register multiple services & components
• Trying to keep DRY

Here is a quick example of how to quickly get up and running

IoC.Configure(c =>

c.Register<IBar>()
.ImplementedBy<Bar>()
.SetProperty(b => b.Message = "Lamda's rocks!")
.UsingFactory<BarFactory>(f => f.CreateBar()),

c.RegisterAssembly("Project.Services")
.ImplementedBy("Project.Components")
);

IoC.Resolve<IFoo>();

I have just completed my third re-write of it and I think it’s finally ready for other developers to have a look at. We are currently using it in production so the code is pretty stable but I’m still going to call it a beta for a little while.

It currently uses Castle’s Windsor but I have wrapped everything Windsor specifc behind interfaces so it shouldn’t be too much extra work to get it working with Spring.Net or any of the other .NET IoC frameworks.

You can get the code from the project home, which also contains all the documentation. Let me know what you think (my favorite type of feedback is checkin’s! ;))

Now that i’m not a student anymore I’ve decided that I can actually afford the £3.41/month to host my own blog so I’m moving from my old blog to here!

Today I need to validate that a user had entered a date in an asp.net calender only to find that there were no solutions for it so for future reference, if you want a calendar validator use the following:

public class CalendarValidator : BaseValidator
{
	protected override bool ControlPropertiesValid()
	{
		return true;
	}

	protected override bool EvaluateIsValid()
	{
		var control = Parent.FindControl(ControlToValidate) as Calendar;

		if(null == control)
		{
			throw new NullReferenceException(
				string.Format(”Could not find the control with id {0} on the page”, ControlToValidate)
			);
		}

		if(DateTime.MinValue == control.SelectedDate)
		{
			return false;
		}

		return true;
	}
}