Unit test Commerce projects with FakeMaker

FakeMaker is updated with support for unit testing Episerver Commerce code. I am very excited about this and hope it will be useful in your projects. The new version is made with contributions and feedback by users of FakeMaker. Thank you! 

Install the new plugin to FakeMaker - called FakeMaker.Commerce - from NuGet, or check out the source code on GitHub. The package currently suppport basic unit testing scenarios. What kind of features are missing? Contact me by creating a GitHub issue, sending a pull request or just write a comment on this blog.

What is FakeMaker?
FakeMaker takes care of mocking and a simplifies creating fake content, that you can use when testing your code.

Unit testing the EPiServer CMS got a whole lot easier alredy with version 7. However, creating fake content to be used when setting up mocked repositories isn't always that smooth. When mocking of code is all you see on your screen, this little library may help. A bigger screen probably also would, but is probably more expensive. FakeMaker make it easier to write unit tests for mvc controllers and helpers that expect the episerver repositories to return content. And now also for creating fake Commerce content.

How does the Commerce support work?
Just like when creating fake pages in FakeMaker

var page = FakePage.Create("MyPageName");

you can create fake products with FakeMaker.Commerce in the same way:

var product = FakeProduct.Create<ProductContent>("My Fake Product");

Add pages and products to the repository and you are ready to go.

fake.AddToRepository(product);

Get FakeMaker
Read more, have a look at the source code and contribute to the project: https://github.com/DavidVujic/EPiServer-FakeMaker

FakeMaker NuGet package: https://www.nuget.org/packages/FakeMaker/
FakeMaker.Commerce NuGet package: https://www.nuget.org/packages/FakeMaker.Commerce/

FakeMaker is updated with Episerver 9 support

Hi Episerver developers!

I have updated FakeMaker (helping you unit test your Episerver code) to support the version 9 binaries. Breaking changes caused compile errors (oops!) and made the tool incompatible with the latest versions of Episerver. It turns out that the base library context no longer has to be mocked, and that's a good thing! The solution was simple: delete code. I love deleting code, maybe even more than writing code.

FakeMaker may help you delete your code.

When writing unit tests, creating fake content and mocked repositories can be a bit depressing. When mocked code is all you see on your screen, this little library may help. A bigger screen probably also would, but is probably more expensive (and won't cure depression).

The latest version is available for download on NuGet, and the source code is on GitHub. Both are targeting version 9.6.1 of the Episerver Core libraries.

If you need Episerver 8 support, download an earlier version from NuGet, or clone the GitHub repo and checkout the epi-8-support branch. 

Please let me know if you have feature requests or run into any issues.


Here's an example of what you can do with FakeMaker: 
you are about to write code that uses the episerver page tree to find pages of a certain type, children of a root node, or maybe just the start page. FakeMaker makes easier to write unit tests for code like that, by creating an in memory page tree and add it to a fake content repository.

Create the pages you need:
var page = FakePage.Create("MyPageName");

or a page of a specific page type:
var myCustomPage = FakePage.Create<CustomPageData>("MyOtherPageName");

Create an instance of FakeMaker:
var fake = new FakeMaker();

Add it to the mocked repository:
fake.AddToRepository(page);

Want more examples?
You will find more examples at the FakeMaker GitHub repo.

Building a bank with EPiServer?

Can it be done?

Yes. And this blog post is about how it can be done. I want to share my thoughts and experiences about writing EPiServer sites, connected to third party services and/or external APIs, with code examples and design suggestions.

 

Should it be done?

Yeah, why not? Long answer: if you already have a nice and smooth communication between product owners and developers - a daily constant flow of feature and content production releases - you probably wouldn't need a Content Management System (CMS) at all. But if you release code a couple of times a month, maybe even longer in between the releases (like most companies out there), a CMS is great to have in place. EPiServer is a good choice for that. Let's build a bank with it!

Actually, I have built one already. Well, no. Not really. But I wrote an example project with some of the building blocks I think an EPiServer site connected to external back end systems should have. 

Here's the code (at Github)
 

I know, I know ... it's a very simplistic example. I wanted to get rid of all the noise, and focus on the "core" stuff that I think is important. I think most of the features in the example code are ready for you to use today, a few things are for demo purposes only (like the implementation of the logger interface). 
 

NoScript First

The example code is an EPiServer MVC site: one page instance with a form that is posted to a controller on the server. The server code is sending the data to an external web service and the service returns user data to be displayed in the user interface. 

Let's zoom in to the form and the posting. All user input should be sanitized and validated. The data sent should be restricted to http POST, along with an anti forgery token. Use the built in model binding and data annotations for the validation of data.

I would recommend you to start developing with JavaScript disabled in the browser. That is a development style I like to call NoScript First. I think it will help you to focus on the security and the basic flow. When you are done with the basics, enable JavaScript and write client side code for a better user experience. You can hijack the form submit action and post the data with ajax, instead of a full page reload.

Here's some more info (with code examples) about NoScript First:
You might not need JavaScript

 

The basics with Dependency Injection

Try keep the controllers as light weight as possible. Extract methods to specialized helper files and inject all dependencies by using a tool like StructureMap. For testability, use c# interfaces instead of concrete classes when injecting the dependencies.

There are trade offs: your source code may seem complex at first look, especially for developers not used to these kind of patterns and abstractions. By hiding the implementations behind APIs (interfaces), you can switch between different implementations, even in runtime. But why would anyone want to do that? I'll will answer that shortly.

 

Isn't unit testing dead?

Dependency injection will simplify testing. A unit test can focus on a specific part of the source code, by providing it with fake implementations of the dependencies and control the data that is passed between them. But why unit test stuff at all? For me, test driven development is a style. A tool, helping me to write code that is specialized, minimalistic and (hopefully) readable. For me, the actual testing is secondary. That's why I think some parts of the source code can be just fine without unit tests. It is alright! However, be strict with unit testing your validation features, like the custom data annotations in the example code. Write unit tests until you are sure that your validation methods does the right thing. Try different scenarios, not only the happy path. Be evil. If you wake up in the middle of the night, because you had dreamed about ways to bypass the validation, write a unit test that prove it. Solve the issue and run the tests again.

To get the dependency injection stuff in place in your controllers, start with a simple unit test "newing up" a controller, develop and refactor the code from there. I think unit tests eventually will help you find the flow, especially when it's done test driven style.

If your controllers handles EPiServer content, such as traversing an EPiServer page tree to create menus or lists, I recommend using FakeMaker - a tool that simplifies unit testing for scenarios like that.

 

Something between the web and the services: Providers

A third party web service or a back end API is probably developed for general purpose, to be used by many different channels. A web site is specialized and customized. The data passed from a service will most likely not fit perfectly with the view of a web user interface. To create a nice user experience, the data probably has to be rearranged in some way (formatted, combined, simplified, renamed). Do that in a separate class library.

Map the data objects from the service to local domain objects that are customized for your user interface. Map the service class properties you need to a local domain object. Let AutoMapper handle the mapping, it's a great tool. Also, make sure you unit test the mappings! Included in AutoMapper, there is a unit testing feature called "AssertConfigurationValid". It has saved my life many times.

Let the library take care of the connection to the service, and keep the user interface unaware of the service API. The library should have only the features needed by the web user interface, no more than that.

I would call a library like that a Provider. Consume the providers by injecting them into the web project code (as described earlier with Dependency Injection). The web communicates with the API (the interface) of a Provider, that means that controllers also are unaware of the actual provider implementation (the concrete class). In the example code, the mappings between interfaces and concrete classes is handled by the StructureMap configuration.

With providers, you can switch service implementations without the need to alter the code in the web project. The same goes for the providers themselves. One provider implementation can be switched to an other one. But why would anyone want to do that? Okay, maybe it's time to give some answers.

 

Fake it!

During development, the back end services may also be developed in parallel and could go offline from time to time. Being dependent on an unstable external service is risky. To be able to write code, browse and test the features of a site, using fake implementations of providers returning fake data is a way out of the problem. Faking it will make it possible for the team to be "offline" and still be productive, i.e. no direct dependencies to a web service or third party system.

There are other practical uses of fake Provider implementations. The site pages that are heavily based on presenting data from back end systems (like an account transaction list) will not look any good at all when logged in as an EPiServer editor (that most likely isn't identified as an existing customer in the back end system). To create a good user experience for editors (and avoiding embarrassing page exceptions in edit mode) fakes can be very useful. Instead of cluttering the controllers with if-else statements all over the place, determining if the current user is an editor or not, you could use your already existing fake providers! That means fake providers actually will be used in production.

To be able to switch between fake and live providers, the injected dependencies need some modification. That is because the StructureMap configuration will run on application start, and checking the logged in user role there won't work. It has to be done per request, triggered from the controllers.

 

Be water, my friend (inject the Factories)

You probably already have noticed in the example code that some sort of factory is injected into the controller, and not the actual provider. The provider is retrieved later in the constructor, by calling a factory method. This occurs on every request. The factory method is where the if-else checking takes place. Is the current user an editor or not? The StructureMap configuration also has two implementations added - one fake, one live - for a provider interface. This makes it possible for the factory to pull the desired implementation from the dependency resolver.

Note: Today I met Jeremy D. Miller (the creator of StructureMap) at the DevSum conference here in Stockholm, and he showed me some examples on how to configure StructureMap without the need of factories. I like it a lot I will try this out (and update the GitHub code repository).

(Okay, maybe this video hasn't that much to do with injecting Factories, but I like Bruce Lee and think this video is cool)

 
What's Pippi Longstocking got to do with it?
Finally, let's talk about the fake data itself. Using this setup, the development team have the opportunity to stress test the UI every day, by providing data that goes beyond the perfect and well balanced placeholder text areas in the design templates delivered by the UX team. 

One obvious thing to test is the name of the logged in user. Here's an idea: add a fake data user with the name Pippilotta Viktualia Rullgardina Krusmynta Efraimsdotter Långstrump (that's the swedish full name of Pippi Longstocking)! How will the user info section of the site behave with a name like that? Well, maybe "Pippilotta Viktualia Långstrump" would be enough, let's not exaggerate. But be aware, in the real world, there are people out there with some really messed up names ... being prepared for it might be a good idea.

What do you think about all of this? Please share your thoughts and ideas about building a bank with EPiServer.

Here's the code (at Github)

EPiServer and programmer friendly analytics with _tics.js

Writing web analytics client side code should be really simple, and programmer friendly. If simple and programmer friendly, teams will have control over the production code they are maintaining, knowing what it actually does. To support that, I wrote a little JavaScript helper library called _tics.js a while ago.

The main features of _tics.js are (besides basic page tracking) advanced event tracking of form fields, buttons and links, including grabbing field values, value changes and the position of clicked links in a banner list or a menu.

What is _tics.js and why should I use it? Read about the features here.

I recently tried out some of the features of EPiServer 8 and came across the new Google Universal Analytics support. My first thought was: Can I use it with the features of _tics.js?

Yes, and here's how.

EPiServer Google Universal Analytics and _tics.js

All you have to do is provide _tics.js with a Tracking Id and the Tracking domain. With the new Google Universal support of EPiServer 8 (installed via the EPiServer NuGet feed), the values are added by an editor in the EPiServer CMS admin view. I have experimented and found a way to grab those values, and it can be done by using the Accessors class in the GoogleAnalytics.Services namespace.

var settings = EPiServer.GoogleAnalytics.Services.Accessors.GetTrackerSettings();

You can now provide the data to the client. 

Here's an example. I have used the Alloy MVC template (and perhaps written the C# model code a bit sloppy, but I leave the clean code implementation to you).

Grabbing the analytics values and storing them in the View Model.

Storing the analytics values in html hidden fields. Initializing _tics.js with data.

With the _tics.events() function, changes in individual form fields will be tracked and will make it possible to analyze user behavior.

In this example, the standard _tics.page() function is not used (i.e. basic page tracking), because it is already being done by the generated analytics code from the EPiServer Google Analytics Nuget package.

Note: Client side code from EPiServer add-ons is rendered by using the Html helper method RequiredClientResources, already used in the Alloy template:
@Html.RequiredClientResources("Header"); 

More features?

What about advanced tracking of form fields, like grabbing the actual values and/or the changes in individual fields? The _tics.js library expect form fields to have data attributes (read more about it here). But when using EPiServer XForms, all an editor can add is custom CSS and none of those fancy data attributes. Oh no!

Relax. I have written a little JavaScript "add-on", called _tics.cms.js, that solves this for you.

You will find it in the _tics.js GitHub repository (look in the folder called "add-ons"). Include it in your code and run the function _tics.cms.prepareForm().

Add the script and run _tics.cms.prepareForm() before initializing the library.

It checks for CSS class names and adds the corresponding data attributes to the element.

An example: this is what the editor writes in the CSS field if wanting to grab the value of an individual field (using the "getValue" built in function in the library). Please note that it is case sensitive: analyze-custom-getValue

And that's it.

Simple? Programmer friendly? What do you think about it? Please share your feedback!

Updates to FakeMaker - helping you with test driven EPiServer development

I have updated the FakeMaker Nuget package with some new features that hopefully will make your days as a test driven EPiServer developer a little bit smoother.

Never heard of FakeMaker? Here's some info.

The updated Nuget package contains new convenience methods when creating fake pages in your unit tests (added the methods WithChildren, WithLanguageBranch, WithProperty and WithContentTypeId). This was developed by Kristian Gimring and I merged it to the source code at GitHub quite a while ago. However, I haven't updated in the Nuget package until now. The current version is 1.0.4.

Recently, I also recieved feedback and suggestions from rbaarda and have added the possibility to set a fake page as the actual StartPage, by using the new method AsStartPage (that will set the EPiServer built in property ContentReference.StartPage).

The dependencies to EPiServer was also outdated, and the latest version of the Nuget package have those and also the Moq library updated. If your current project is not using the (as for now) latest version of EPiServer, I would suggest you to grab the source code instead (two files only: FakeMaker and FakePage), add it to your test project and compile, instead of using the Nuget package version.

I want to thank Kristian Gimring and rbaarda for the contributions. I really appreciate it and am happy to see that the tool is used! 

What features are missing? Let me know! Please contact me by writing a comment in this post, at twitter, as a GitHub pull request or just add an issue to the GitHub project.

Dynamic forms - with a keep it simple approach

Wouldn't it be cool if editors just could drag-and-drop input fields and rearrange the design of forms in EPiServer? I can almost hear you say: XForms. Yes, I've heard about it. I have written a fair amount of code using the good ol' built in EPiServer feature. I have even succeeded in taming the XForm Beast to obey the simple rules of MVC (with help from you great bloggers out there). But that is a different story.

What about the forms that need other features than the ones provided by EPiServer XForms?

An example scenario:
We want to collect user input by using a web based form. The input data should be passed on to a back end system for processing, and should not be stored in the EPiServer database at all. Additionally, the editors want to create different campaign pages with different forms. The editors want to A/B test the campaign pages - to learn how to reshape and adjust the form to maximize conversion rates. Can this be done with EPiServer?

Here's a simple solution: blocks.
(check out the full example at GitHub)

The Input Block
Let's write a block type that can be used in forms all over the site. Instances of the block type will behave in different ways, when used in different contexts. To succeed with that, each instance of the block type need to have really good answers to some existential questions:

What am I?

Where do I belong?

How should I act in public?

The answers come in the form of categories. It doesn't have to be like that, It's just me. I think categories are cool. They remind me of twitter hash tags (I think twitter hash tags are cool too).

What am I? (Field) Where do I belong? (Group) How should I act? (Behaviour)

This instance is a "first name" input field, existing in a "user" context,

with user input set to required.

The View
Now we have the answers to the deep questions asked earlier and can write the user interface. 

The example code has some convenience methods, 

such as generating the input field name based on the categories.

Html output generated with data from the model (the block type).
A server side regular expression pattern is also passed on to the client.

The Validation
What about validation? Dynamic forms are by nature quite unpredictable. But we know about the behaviour of the individual block, and can use that knowledge to write both custom client and server validation. In this example I am using the Zurb Foundation Abide framework to perform client script validation. 

Custom validator added to the Abide framework, 

specialized in validating first name input fields. 

The name of the validator is the value of the selected subcategory for "Field".

"David" is valid. Nice to know.

This example code has two types of server validation. First up is the data annotations defined in the model. Secondly (if necessary) there is also the ability to perform custom validation. What validator to use is determined by the block behaviour (the categories), just like selecting the client validator. Here is where specialized validation takes place, such as dependencies between individual fields in the posted form.

Form data posted to the controller action method.

Going through each item in the page content area,

find the appropriate validator and execute the validation method. 

The model is passed to the validator.

That's it.

Check out the example code at GitHub. To get up and running you need to create an EPiServer 7.5 database and (of course) configure the connectionstrings file.

I really want your feedback on this. 

Please post your comments here or contact me on Twitter.

Quick Start: EPiServer 7.5 & mvc - the minified version

What is EPiServer and what does EPiServer 7.5 do? 

I (think) that I have aswered those questions during lunch hour today here at Knowit in Stockholm. 

This video - in swedish - is a minified version of my talk & live coding about the CMS, using asp.net mvc to demo how page types, properties, editor features and pages are wired together (without complicating things too much).

Do you have feedback about this presentation? Please contact me by writing a comment at this blog post or at twitter.

FakeMaker - helping you with test driven EPiServer development

Test driven development and EPiServer?

Relax. Test driving the CMS actually got a whole lot easier with version 7. Most of the built in features are implementing interfaces and you can use asp.net mvc. Those ones are two really good friends of test driven development. However, creating that fake content and set up mocked repositories isn't really as smooth as it should (could) be, right?

When mocking code is all you see on your screen, this little library called FakeMaker may help you. Okay, a bigger screen also would, but is probably more expensive. With FakeMaker, you have two classes: FakeMaker and FakePage. The FakeMaker class takes care of the mocking and FakePage helps you create content.

Here's some examples.

Create an instance of FakeMaker:
var fake = new FakeMaker();

Create the pages you need:

var page = FakePage.Create("MyPageName");

or a page of a specific page type:

FakePage.Create<CustomPageData>("MyOtherPageName");

Add it to the mocked repository:

fake.AddToRepository(page);

You can now pass the fake repository to your code (also known as Dependency Injection) from the ContentRepository property or use the built in EPiServer ServiceLocator feature.

Please let me know what you think about it.

Check out the documentation, the examples and the source code:

https://github.com/DavidVujic/EPiServer-FakeMaker

You will also find FakeMaker at NuGet:

https://www.nuget.org/packages/FakeMaker/

Upgrading to EPiServer 7.5 - without the headache

Earlier today I managed to transform the day from huge #FAIL (with headache) to the good feeling of #SUCCESS (headache gone). Oh, this is not twitter. Sorry, I forgot. 

The project I'm involved in currently, we develop an application with EPiServer 7 (it's actually 7.1 to be precise) and I personally enjoy the product being a lot more testable than ever before. Stay tuned for an upcoming post on test driven development with EPiServer. (and there goes the holidays ... why did I promise that?).

The latest version - 7.5 - was recently released and since we are at the beginning of the project there cannot be a better opportunity for an upgrade. So, we made the decision to at least give it a try.

There is an upgrade guide at the EPiServer World site, but I guess there are a couple of scenarios that the team over there did not try out. I have sent them feedback on this and some issues raised here will probably be solved shortly.

Have a look at the upgrade guide.

I suggest that you follow the upgrade guide along with the stuff I describe here. 

Before you start, I recommend that you take a copy of the database and use the copy when upgrading (don't forget to update the connectionstrings configuration file). 

The first impediment I ran into was that the installer failed because the site was using a VPP folder in an external share. Before you run the installer, copy the VPP folder to your local disk and update the episerverframework configuration file.

If you would wake up in the middle of the night and realize upgrading was a bad move, all you need to do is a rollback of the source code. You only messed up the copy of the database and the local VPP folder. Don't worry.

Follow the steps 1-9 in the guide.

The following step in the guide is about updating the assembly references. Here is a bug. In our project we have added the assemblies from the EPiServer NuGet feed and to update without the headache this what one need to do: right click the references folder, select "Manage NuGet packages" and navigate to the Installed packages folder. Uninstall the references to "EPiServer.CMS.Core" and "EPiServer.Search".

Next up is where I found the bug: when I browsed the new assemblies in the EPiServer feed and installed them, the reference to StructureMap had the wrong version and the code would not compile. What I did was to install StructureMap from the official NuGet feed first. Then I went back to the EPiServer NuGet feed and installed "EPiServer.CMS.Core" and "EPiServer.Search". The previously installed version of StructureMap was already there and was not overwritten.

Here is the version existing in the EPiServer NuGet feed.

Here is the newer version from the official NuGet feed.

The solution is ready to be built. Most likely the compilation will fail, because of the breaking changes of the 7.5 version. Step 12 in the guide is about making the source code changes.

One thing that I find confusing is the code existing in the EPiServer.UI assembly. We have written a custom report in this project and that needed to be updated. The new stuff to use is within the namespace EPiServer.Shell, but the actual assembly is EPiServer.UI. And that assembly isn't referenced when getting the stuff from the EPiServer NuGet feed. So, what did I do? Well, I picked up the local dll from the EPiServer installation folder (the 7.5 folder).

Confusing, isn't it?

Finally, the code actually compiles without any errors. Tadaa!

But wait. Don't browse the site! I did that. And it lead me to the wrong problem solving path. Headache. The site should actually not be browsable at this point, and that is fine. So, move on to the next step in the guide and run the update add-ons stuff from the Deployment Center.

By now, the upgrade is almost done. So close, and yet so far away. The next move is to migrate the VPP files into the new media system. The guide mentions the VPP Migration Tool. But where is it? Guys, a link to the download page from the guide would save us lots of time (and headache). Finally I found the tool at the download page for the CMS 7.5 page (the column to the right with the header "You might also want to download"). 

Almost done. Don't give up! Have a banana and drink some water.

It's time to follow another guide: Migrating VPP-based files to the new media system.

I added the classes GenericMedia, ImageFile and VideoFile. I still am not sure if that really was needed. The guide describes the code as just examples. To be safe I also regenerated the GUIDs with some help from Visual Studio.

The final impediment is the kind of problem that is so simple, but sometimes so difficult to see. I think it's about that tree and the forest, you know? The Migration Tool threw an exception when I tried to connect to the site. The exception was about not being allowed to use external assemblies. "What? Where? Who?"

Man, did I google to find a solution. Whew!

The executable file itself was blocked by Windows since it was a downloaded file. By right clicking it and selecting properties, the "Unblock" button will appear. Click it. Just do it. Run the Migration Tool again and you will finally be able to tweet #SUCCESS.

The things described here has been verified in two different virtual machines, one with Windows Server 2012 R2 and the other one with Windows 8.1 Pro.

Good night.

Hipster or neckbeard?

Man, that (asp.net) webforms thing really suck, doesn’t it? We should convert all our sites to mvc. For all the new stuff we’re about to develop, there is only one way: mvc. But wait a minute. I forgot to ask.

Why?

If you are developing stuff for the EPiServer CMS product, choosing between the two is a big thing these days. I think many EPiServer developers has felt left behind (myself included), being stuck with webforms when the rest of the world writes cool and awesome stuff with mvc and the frameworks that comes with it. I guess those poor SharePoint guys feel the same, don’t you think?

The times are different now. All of us can be cool these days (well, almost all of us. SharePoint will get there too some day).

Ok, so it’s about being cool?

Maybe. I would choose mvc because of one thing only: test driven development (tdd). Mvc is designed for that. Webforms isn’t. The rest is just style and preferences: design patterns, view engines, frameworks.

Is test driven development cool?

I think tdd is a great tool for helping you create both short term and long term value. The result will most likely be a product with nice and simple code. Nice & simple, as in easy to understand, maintain and refactor. Test driven development with webforms is mostly depressing. But hey, that is a different blog post.

Writing testable code, huh?

Well, I’m not really talking about just writing testable code. Don’t do that. Do test it & the code will follow. That's doing it the test driven way.

So who is the cool guy then, webforms or mvc?

I don’t know if anything used together with .NET and Visual Studio can be considered cool, really. We should probably check with @hipsterhacker or @neckbeardhacker about that. But don’t just settle with writing testable code with asp.net mvc. Without unit tests that proves it, the code base won’t probably be testable anyway.

So, without unit tests all that is left is choosing by style and preferences. Think about if that generates any value. Then make your decision on which way to go.

ps.

Check out my recent posts and videos on test driven development:

From the streets of test driven development: JavaScript

aspConf 2012 - Quick start: test driven development

ds.