Blog posts by Cristian Libardo

Spark View Engine on WebForms

Tue, 16 Nov 2010 21:39:00 GMT

Spark view engine is a neat little web utility that allows you to write code like this:

<viewdata products="IEnumerable[[Product]]"/>
<ul if="products.Any()">
  <li each="var p in products">${p.Name}</li>
</ul>
<else>
  <p>No products available</p>
</else>

If your eye skipped over it because it looks just like html I wouldn’t blame you. But look again. Loops and conditions are nicely embedded in html. Spark really does let the html dominate (which can be a good thing). These are but a few of all the nice features. If you have them, spend a couple of minutes browsing the spark documentation to learn what’s more.

To learn a bit about the inner workings of this wonderful tool I set out to add WebForms support. The spark codebase has a very testable design and can be coerced to help out in a WebForms control without modification. The end result look like this:

<spark:View runat="server">
  <ul if="Container.GetProducts().Any()">
    <li each="var p in Container.GetProducts()">${p.Name}</li>
  </ul>
  <else>
    <p>No products available</p>
  </else>
</spark:View>

Download and usage

To use it download

Spark.Web.Forms.zip

and unzip into your bin folder.

<pages>
  <controls>
    <add tagPrefix="spark" namespace="Spark.Web.Forms" assembly="Spark.Web.Forms"/>

Add something useful to iterate over to your page or user control:

public string[] Values;
protected void Page_Load(object sender, EventArgs e)
{
  Values = new string[] { "Simple", "As", "Pancake" };
}

And add the spark control:

<spark:View runat="server">
  <ul>
    <li each="var c in Page.Values">${c}</li>
  </ul>
</spark:View>

Future improvement ideas

Some features are definitely missing (and they might require modification of the spark code itself):

Spool content from a spark view controls placed later in the control tree
Cache the compiled views
Support the spark cache element

The code is over here.

Testing templates without creating a page using TemplateMock

Thu, 23 Sep 2010 17:02:42 GMT

Sometimes it’s useful to test your code before committing it. When possible unit tests make for a nice way to do this. Template code, however, is not always the most easy to test as a unit. This is when a UI testing framework such as Selenium can come in handy. Unfortunately creating the pages to test can be a bit cumbersome and this is where TemplateMock helps out.

Usage

TemplateMock allows you to access a page type without creating it in edit mode from a known URL. After adding templateMock to your site you can render a standard page using an alternative url:

/TemplateMock.ashx?scenario=[Public]+Standard+page

Configuration

When navigating to TemplateMock without query parameters you can choose which template to execute:

Optionally you can add query parameters to configure it:

randomize (true/false): Wheter the content on the page is deterministic (doesn’t change every time)

numberOfChildren (0-n): How many children this page appears to have

For example “/TemplateMock.ashx?scenario=[Public]+Standard+page&randomize=false&numberOfChildren=100” will render a standard page with 100 child pages without randomizing it’s content.

It’s also possible to tweak other aspects from code. This is left as an excercise to the reader.

Download & installation

Be aware that TemplateMock broadcasts unsupported pirate signals to hack into the CMS core and should never be used in production.

TemplateMock.zip

To install it just unzip in your site’s root directory and navigate to TemplateMock.ashx.

Don’t even try using MVC2 on CMS6

Wed, 08 Sep 2010 16:52:00 GMT

...yet. Unfortunately it’s not possible to use ASP.NET MVC 2 on CMS6 (without running into a lot of trouble). The reason is that parts of EPiServer uses MVC1 and there are breaking changes between MVC1 and MVC2 preventing a simple assembly redirect.

The offending changes

The particlar changes that cause problems in this case are these:

Http GET and return Json needs to be explicitly allowed in code return Json(…, JsonRequestBehavior.AllowGet);
Change of return type to MvcHtmlString on html helpers
Async controllers feature introduces a new way of calling the controller factory

Future upgrades of ASP.MVC

Now, if you’re using MVC1 please be aware that we’re planning to update ASP.NET MVC to version 2 and that you might be affected by changes above, or any of the other changes described in the ASP.NET MVC 2 RTM release notes

I’ve heard several requests to use MVC the second. If you feel this upgrade might be a problem don’t hesitate to add your comment below.

Shell Playground

Thu, 25 Mar 2010 10:37:00 GMT

Sometimes it’s okay to have fun. A while back we had fun trying things in OnlineCenter and the result is the Playground. For designers this is a catalog of styles available on the dashboard. For developers it’s an insight into the OnlineCenter API.

In the playground project you will find examples of…

…CSS classes and element styles

…server side ajax helpers

…form element styles

…an example using jTemplates and json

…how we deal with errors

…adding interfaces to the menu system

…the AppDomain search provider

As well as a few other things. Keep in mind that this isn't best practice. It's just code.

Download

And finally, the actual download

To try this out you will need to build and configure the project in web.config.

Legacy redirect in CMS 6

Tue, 16 Mar 2010 13:23:00 GMT

Fredrik wrote a very interesting and informative post about changes to the configuration files. The post also brings a whole new meaning to the term configuration management.

An issue brounght up are changes of the URL to the edit and admin interfaces which causes existing bookmarks to break. This can be fixed using the downloads below. The module redirects requests to files that exist in edit/admin from the old to the new path.

We decided to pull this from the release since we didn’t have time to fully analyze the consequences of including it. There are two different downloads due to breaking changes to the initialization between RC and RTM.

Download EPiServer.LegacyRedirect for CMS 6 RC

Download EPiServer.LegacyRedirect for CMS 6 RTM (not yet released at the time of writing)

What and why is epiJQuery?

Fri, 12 Feb 2010 17:14:00 GMT

A feature in EPiServer CMS 6 that might catch your eye is a dashboard. An interesting technical aspect of it is that it’s largely a client based solution. As such anyone planning to do their magic on it might have the good fortune to enter the wonderful world of client side scripting (but you can do a lot of things server only if you prefer that).

So, what is epiJQuery? It’s jQuery 1.3.2, with one tiny addtition:

window.epiJQuery = jQuery;

Why is this useful? Consider this seemingly innocuous line anyone could add to the dashboard at any time.

<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.4/jquery.min.js"></script>

The additional variable epiJQuery ensure that any scripts running after the script include above will find the same jquery version and plugins as the ones running before the script include.

Quick intro to ASP.NET MVC for the WebForm developer

Tue, 19 Jan 2010 14:25:32 GMT

To prepare for future discussions around dashboard gadgets I thought it was a good idea to introduce the ASP.NET MVC framework.

The main buidling blocks of the ASP.NET MVC framework is routing, controllers, views and the model support. There are also multiple hooks in and around these blocks to bend the behaviour to your wim.

Routes

Routes are registered to handle an incoming URL pattern and map it to your code along with parameters, and back from parameters to an URL. A route registration typically is a piece of code in Application_Start that may look like this:

routes.MapRoute(
  "Default", // Route name
  "{controller}/{action}/{id}",// URL pattern with parameters
  new { controller = "Home", action = "Index", id = "" } // Defaults parameters
);

This will register a route that accepts anything from 0 to 3 segments and matches each segments to the corresponding parameter or the default.

E.g. URL = "/hello/world/1" is matched to controller = "hello", action = "world" and id = "1"

The default parameters mean that the URL = "/" would be matched to controller = "Home", action = "Index" and id = ""

Such routes can be configured to handle a lot of scenarios and more. Keep in mind that routes are organized in a table which is evaluated from fist to last, the first to match is used.

Controllers

This is the handler for a piece of functionality. By way of routing a method is invoked in which you decide what action to take. The action may be rendering one view or another, redirecting to somewhere else, or returning a JSON string that is easily interpreted on the client.

A controller may look like this:

public class HomeController : Controller
{
  public ActionResult Index()
  {
    return View();
  }
}

This is a controller that given the route above responds to everything from "/" to "/home/index/whatever". An interesting aspect of route parameters that they are used to call the action method, e.g.:

public ActionResult Index(int id)
{
  return View();
}

This will convert the {id} parameters into an integer or throw an exception if this isn't possible. Also the query string, and form values are also fitted into the method arguments when possible. The view model may be any kind class (e.g. a list of persons or an address object) and it's used on the view to render HTML. Very worth mentioninng is that the controller logic is (unit) testable.

Views

By default views are ASPX pages inheriting from a base class that provides useful properties. Rather than using the control hierarchy and the page lifecycle to construct the interface plain html and extension methods (html helpers) are preferred. A fundamental difference is that controls needn't reconstruct their state on postback. Instead, plain old HTTP POST/GETs target a controller action and posted data doesn't pass through a server control.

E.g. WebForms:
<asp:TextBox ID="Name" runat="server" />

MVC:
<%= Html.TextBox("Name") %>

One of the appealing aspects of this model is that AJAX interaction becomes very easy as the HTML can live on the client and interact with a controller without the need to keep the server control model up to date.

Model

The model are simply classes that reflect the problem the application tries to solve. These classes can be used and tested separately from the presentation. ASP.NET MVC doesn't propose any particular database tooling. Most of the time you would use an O/R mapper to get a class instance, update it and pass it along to a view. What the framework will do is to give a lot of support in updating, and working with any class within controllers and views.

E.g. consider the following actions:

public ActionResult Index()
{
  return View(new Person { Name = "Fill me up scotty" });
} 
public ActionResult Update(Person person)
{
  Store.Save(person);
  View("Index", person);
}

And this view code:

<% using(Html.BeginForm("Update", "Home")) { %>

  <%= Html.TextBox("Name") %>

  <input type="submit" />
<% } %>

Not only will the MVC framework popuplate the input box with the name of the person. It will also repopuplate a person object in the Update method when the form is posted. Other nice features include validation support, the possibility to post to any action on any controller and an abundance of options that might better fit your fancy.

Summary and some pitfalls

As you may have noticed this model brings you much closer to the web. While MVC does a lot of handholding a web application developer is faced with other responsibilities and options. Anyone without a strong investment in web forms will probably find themselves at home.

A controller doesn’t have a specific URL. This is the concern of a route.

The web control developer entering this world will probably start looking for new forms of code reuse.

Enabling gadget development quickly

Mon, 18 Jan 2010 15:07:00 GMT

Preparing your project for gadget development is as simple as tweaking a few xml files. In fact, it’s so easy even a machine can do it if you download and execute the following file through Deployment Center:

Add MVC Gadgets to PublicTemplates.epimodule

What does it this do?

1. It alters PublicTemplates.csproj:
* Adds references to System.Web.Mvc.dll and EPiServer.Shell.dll (these contain classes you need doing gadgets)
* Adds the ASP.NET MVC project type guid (this enables the Visual Studio tooling)
* Alters the project to include gadget example

2. It copies a simple gadget example to the project folder.

3. It modifies web.config registering EPiServer.Templates.Public as a public module.

What doesn’t it do?

It doesn’t install ASP.NET MVC (this needs to be installed separately)

What if something goes wrong?

Squeak here below and I’ll try to help.

Where can I get it?

Here (download)

Breaking changes between EPIServer 6 CTP2 and Release Candidate

Mon, 28 Dec 2009 17:26:00 GMT

Rather than enumerating every change between preview 2 and the release candidate we downloaded a few of the winning gadgets and made the required changes to make them work on the RC version.

This is the list of changes. Please feel invited to share any other breaking change that isn't listed here.

1. On the client, the gadget instance is passed directly instead of gadgetContext which has been removed

// from
function fcsm_initialize(e, gadgetContext) {
    fcsm_gadgetInstance = gadgetContext.instance;
// to
function fcsm_initialize(e, gadget) {
    fcsm_gadgetInstance = gadget;

2. The extensions in Shell Extensions now lives somewhere else

// from
<%@ Import Namespace="EPiServer.Shell.Extensions" %>
// to
<%@ Import Namespace="EPiServer.Shell.Web.Mvc.Html" %>

3. The dynamic data store has gained a factory

// from DynamicDataStore<ReportSettings> store = DynamicDataStore<ReportSettings>.CreateStore("AnalyticsGadgetStore", false); // to DynamicDataStore store = DynamicDataStoreFactory.Instance.GetStore("AnalyticsGadgetStore") ?? DynamicDataStoreFactory.Instance.CreateStore("AnalyticsGadgetStore", typeof(ReportSettings));

4. The dynamic data store “Find” has changed

// from store.Find("GadgetId", gadgetId).FirstOrDefault<ReportSettings>(); // to store.Find<ReportSettings>("GadgetId", gadgetId).FirstOrDefault();

5. The dynamic data store LINQ has changed

// from
from alertCollection in store
     where …
     select alertCollection;
// to
from alertCollection in store.Items<AlertMethodCollection>()
     where …
     select alertCollection

6. The gadget contracts namespace has moved

// from
using EPiServer.Shell.Gadgets.Contracts;
// to
using EPiServer.Shell.Gadgets;

7. Some resource texts have been moved

// from
[GadgetAction(ActionType.Menu, TextResourceKey = "Edit", 
    ResourceType = typeof(EPiServer.Shell.UI.Views.Shared.SharedResources))]
// to
[GadgetAction(TextResourceKey = "Edit", 
    ResourceType = typeof(EPiServer.Shell.Resources.Texts))]

8. The configuration has changed to reflect that we now split modules by protected and public (added december 30)

// from
<episerver.shell>
  <siteSettings rootPath="~/U/" />
  <modules autoDiscovery="Minimal">
    <add name="DdsExplorer">
      <assemblies>
        <add assembly="DdsExplorer" />
      </assemblies>
    </add>
  </modules>
  <frameworkModules>
    <add name="Shell">...</add>
    <add name="CMS">...</add>
  </frameworkModules>
</episerver.shell>

// to
<episerver.shell>
  <protectedModules rootPath="~/U/">
    <add name="Shell" />
    <add name="CMS" />
  </protectedModules>
  <publicModules rootPath="~/public/" autoDiscovery="Minimal">
    <add name="DdsExplorer">
      <assemblies>
        <add assembly="DdsExplorer" />
      </assemblies>
    </add>
  </publicModules>
</episerver.shell>

9. Some style classes have a different name (added december 30)

//from
<div class="epi-defaultPadding">
<div class="epi-smallPadding">

//to
<div class="epi-padding">
<div class="epi-padding-small">

I also took the liberty of uploading the changes to codeplex. I take no responsibility for the quality of any gadget or any introduced errors. All credits goes to the original author. These are the gadgets that were updated:

Let me know right away if a gadget needs to be removed or if you need access to change a release.

Exploring the data lair

Sat, 21 Nov 2009 10:55:00 GMT

Arm yourself with the DDS Explorer and venture into the dark bowels of your EPiServer CMS 6 site.

Find what stores there are.

Learn the kinds and sizes of shelves in the store

Take a peek at what lies in store for you.

And change it!

Download DDS Explorer (Take care not to do anything nasty with this)

In summary

The dynamic data store is a great new feature. The setup cost is almost zero and using it is so easy you almost forget you're using a database. The (almost) fixed schema operation also promises a nice deployment scenario.

Tic Tac Gadget

Sun, 08 Nov 2009 18:48:00 GMT

This is totally cool gadget. Who can resist a multi (well 2) player game?

It's also totally useful. Instead of procrastinating web editors, business owners and developers alike can spend hours competing among themselves on the dashboard. On a 1 to 10 scale the business value of this gadget is negative.

The technical quality is totally over the top. The gadget features the most snazzy silverlight interface imaginable (you know, rich internet applications) and a super-cool duplex WCF service connection for instant feedback and the quickiest of games.

To make things even better it's all totally open. The code is completely exposed ~~in the most embarassing of ways~~ over at codeplex.

Obviously, the gadget is totally in time for the market. A gadget is never late, nor is it early, it arrives exactly when it was meant to.

You will find the download along with installation instructions over here.

Happy playing!

CTP2 gazing upon the world

Tue, 20 Oct 2009 10:49:00 GMT

Not yet a day old CTP2 gazes upon the world with misty eyes.

Looking upon herself she sees a new shiny surface on top, and things underneath that will bring her far.

She soon discovers that she can be beautified with the help from others and already some and others have written tales about it.

This is all very exciting and she can't wait to see what people are competing about.

Jumping on the page type bandwagon

Fri, 17 Jul 2009 22:51:00 GMT

With the sun shining and the thermometer approaching body temperature I thought it was god time to have some fun. Quick from thought to action I fired up my trusty black warrior to explore another white spot on the map.

My objective for the day was to get to get aquainted with the page type builder. One of those really neat features your manager never will understand.

I was pleased from the first moment to notice that after including it in my solution and adding my page type it worked right away. It's just like magic, and I cannot but love the firm presence of a piece of text sitting in my source code repository.

The natural next step was learning about the inner workings. Living on the practical side of the fence I tend to learn best by using, exploring and finding interesting aspects to change. With the using already under my belt I ventured into the exploration phase.

Some mental mapping revealed some logical roles:
* An API to map code to episerver page types and the discovery thereof
* Synchronization between code and database for page type settings and properties
* A data factory wrapper to access the typed pages

Looking for interesting aspects to change I first took aim at the startup process. The page type builder uses a very cleverly constructed plugin attribute to trigger the build up and synchronization the page types. Beeing slightly paranoid I wanted this a bit more explicit. At the price of a tiny bit of extra code comes a cosier feeling of control.

 protected void Application_Start(Object sender, EventArgs e)
 {
    PageTypeBuilder.Initializer.Startup(PageTypeBuilder.InitializerOptions.CallProperties);
 }

The actual initializer then waits until the opportune moment (EPiServer is initialized during the first request) and then synchronizes:

 public static void Startup(InitializerOptions options)
 {
  EPiServer.Web.InitializationModule.FirstBeginRequest += InitializationModule_FirstBeginRequest;
 }
 
 static void InitializationModule_FirstBeginRequest(object sender, EventArgs e)
 {
  PageTypeBuilder.Synchronization.PageTypeBuilder.UpdatePageTypes();
 }

The next change is about pushing typed page data objects into the EPiServer APIs. One particular aspect I like about the page type builder is the way it fits with the existing model. Re-tailoring for an even tighter fit I latched onto the data factory event system to push the typed pages down the stack and into EPiServer.

 public static void Startup(InitializerOptions options)
 {
  //...
  EPiServer.DataFactory.Instance.LoadedPage += DataFactoryInstance_LoadedPage;
 }
 static void DataFactoryInstance_LoadedPage(object sender, EPiServer.PageEventArgs e)
 {
  Type type = TypeResolver.GetTypeForPageType(e.Page.PageTypeID);
  //...
  e.Page = Activator.CreateAndPopulateInstance(e.Page, type);
 }

The final and most fun change is related to the property usage. This is how strongly typed properties can be constructed:

 [PageTypeBuilder.PageTypeProperty]
 public string SecondaryBody 
 {
  get { return GetPropertyValue<TextPage, string>(p => p.SecondaryBody); } 
  set { SetPropertyValue<TextPage, string>(p => p.SecondaryBody, value); }
 }

This approach while very pragmatic is not the most readable. The property getters and setters are responsible for using the correct property data and the lambdas provides some nice refactoring support. Inspired by one of my colleagues I decided to extend this using one of my favorite toys: DynamicProxy2. After introducing a dynamic activator the code in the page type would look like this:

 [PageTypeBuilder.PageTypeProperty]
 public virtual string MainBody { get; set; }

Slightly less, isn't it? Of course the code for the activator itself is a bit longer, but not that long. Instead of creating a regular page data instance it uses DynamicProxy2 to create a special instance with a method call interceptor (it overrides and intercepts the getting and setting of properties). The interceptor then analyzes calls to the page data objects and uses GetValue/SetValue instead of calling the actual properties.

Update (20 july): Krzysztof pointed out a more elegant solution using proxy generation hooks and the code has been updated.

    protected override TypedPageData CreateInstance(Type typedType)
    {
        (TypedPageData)generator.CreateClassProxy(typedType, options, interceptors);
    }

Creating the page proxy will allow for this interceptor to be called instead of the reguar property.

    internal class PageTypePropertyInterceptor : IInterceptor
    {
        public void Intercept(IInvocation invocation)
        {
            string propertyName = invocation.Method.GetPropertyName();
            if (invocation.Method.IsGetter())
                invocation.ReturnValue = page.GetValue(propertyName);
            else
                page.SetValue(propertyName, invocation.Arguments[0]);
        }
    }

The generator hook allows us to select which properties should be intercepted.

    internal class PageTypePropertiesOnlyProxyGenerationHook : IProxyGenerationHook
    {
        public bool ShouldInterceptMethod(Type type, System.Reflection.MethodInfo memberInfo)
        {
            return memberInfo.IsGetterOrSetterForPropertyWithAttribute(typeof(PageTypePropertyAttribute))
                && memberInfo.IsCompilerGenerated();
        }
        //...
    }

Boy, that was fun! And educative. Hope I didn't overdo it and that some of this (thoroughly untested) experimentation can be of any use. Oh, and here's the code in case anyone is interested.

Zip Installer

Wed, 14 Jan 2009 17:11:35 GMT

The upcoming SP1 release of EPiServer CMS R2 will be accompanied by a long lost friend. The Zip Installer.

Since many of her pals have been missing her and wondered about her well-beeing we thought to invite her back to join our new home.

She did change her name, along with another few things. One must wonder what she has been doing all this time. Better not ask. What matters is that she looks healthy and in good shape.

Welcome back old friend.

R2 and unit testing

Thu, 16 Oct 2008 08:34:00 GMT

I've been exploring the unit testing story in the latest EPiServer release and so far I've been pleasantly surprised. R2 brings some improvements in this respect. Most of the time I can execute my tests without chatting with the database or faking the http context.

The key to this is the page provider. I'll briefly cover the basics of setting up a test with a fake page provider and offer tools to help you along.

Why unit test? A healthy set of unit tests has saved my butt more than a few times and if you're at least half-serious about software development you should be looking after yours.

How to do it

Step 0: envision the business requirements

"As a user I can submit a suggestion so that a support representative can review it and publish it for everyone to vote"

Step 1: write a test

For the purpose of this example I'm choosing NUnit because of the nice fluent syntax helpers. The test creates a suggestion and submits it to the suggestion box. Then we assert that the suggestion can be retrieved.

    [TestFixture]
    public class SubmittingSuggestions
    {
        [Test]
        public void WhenSuggestionIsMade_ItsAddedToTheBacklog()
        {
            SuggestionBox box = new SuggestionBox();
            Suggestion original = new Suggestion("Make it stop", "I see no end to the possibilities");
            box.Submit(original);

Suggestion retrieved = box.Dequeue();

            Assert.That(retrieved.Title, Is.EqualTo(original.Title));
            Assert.That(retrieved.Body, Is.EqualTo(original.Body));
        }
    }

Step 2: make it pass

A simple suggestion box implementation:

    public class Suggestion
    {
        public Suggestion(string questionTitle, string questionBody)
        {
            Title = questionTitle;
            Body = questionBody;
        }

        public string Title { get; set; }
        public string Body { get; set; }
    }

    public class SuggestionBox
    {
        Queue<Suggestion> questions = new Queue<Suggestion>();

        public void Submit(Suggestion suggestion)
        {
            questions.Enqueue(suggestion);
        }

        public Suggestion Dequeue()
        {
            return questions.Dequeue();
        }
    }

Step 3: refactor

The test passes but it's not a terribly permanent way to store our suggestions. For the purpose of a real application this is just a fancy way of creating heat. We need to go back to the test and think again.

Step 1: think again

We change the test to assume we store the questions as a page in an episerverp age container. Doing so is nice since it allows the support representative to review and publish the suggestion from within the edit interface.

private PageReference boxLink;

        [SetUp]
        public void SetUp()
        {
            PageData box = DataFactory.Instance.GetDefaultPageData(PageReference.StartPage, SuggestionBoxPageTypeID);
            box.PageName = "Suggestion box";
            boxLink = DataFactory.Instance.Save(box, SaveAction.Publish, AccessLevel.NoAccess);
        }

        [Test]
        public void WhenSuggestionIsMade_ItsAdded_ToTheSuggestionBoxContainer()
        {
            SuggestionBox box = new SuggestionBox(boxLink, DataFactory.Instance);
            Suggestion original = new Suggestion("Make it stop", "I see no end to the possibilities");
            box.Submit(original);

PageDataCollection stored = DataFactory.Instance.GetChildren(boxLink);

            Assert.That(stored[0].PageName, Is.EqualTo(original.Title));
            Assert.That(stored[0]["MainBody"], Is.EqualTo(original.Body));
        }

Step 2: make it pass

Now the fun begins. We've already introduced a reference to EPiServer but we need to initialize it. For this purpose I've created a little helper that creates a fake page provider that doesn't use the database. I won't go over the details but the can be downloaded at the end of the article. For now we just reference EPiSugar.Utilities and tweak the test (sorry kent):

        [SetUp]
        public void SetUp()
        {
            EPiSugar.UnitTesting.Fakes.Initialize(new FakeStructureBuilder(1, 0));
            ...

As you would soon discover, we need a few more things:

A license.config whose properties is set to "Copy to Output Directory": "Copy if newer"
And an app configuration: for this I'm just using the contents of my web.config and adding connectionStrings.config

This is how the new and improved implementation looks like:

public class SuggestionBox
{
    private const int SuggestionPageTypeID = 11;
    private readonly PageReference containerLink;
    private readonly DataFactory dataFactory;
    public SuggestionBox(PageReference containerLink, DataFactory dataFactory)
    {
        this.containerLink = containerLink;
        this.dataFactory = dataFactory;
    }

    public void Submit(Suggestion suggestion)
    {
        PageData page = dataFactory.GetDefaultPageData(containerLink, SuggestionPageTypeID);
        page.PageName = suggestion.Title;
        page["MainBody"] = suggestion.Body;
        dataFactory.Save(page, SaveAction.Publish, AccessLevel.NoAccess);
    }

    public Suggestion Dequeue()
    {
        throw new NotImplementedException();
    }
}

Time to run some tests... Wohoo!: 1 passed, 0 failed, 0 skipped

Step 3: left as an excercise to the reader

Conclusion

Don't let the simplistic example put you off. One simple test at the time we can achieve great feats. I can't say such tests arn't ideal for UI testing in my experience. Would you have any experiences to share in this area?

Using a faked page provider can really help speed up the tests and smoothe the pain of setting up test data. The great thing is that we don't need to modify the database state. EPiserver has reached a long way in terms of testability. It's far from perfect, but the road never ends. Doesn't it?

Download the example test + the EPiSugar utility. You can also get it directly from the source code repository. Hope this can be useful to you.