Test Driven Development Deluxe

You have probably already heard about the red-green-refactor workflow when practicing Test Driven Development: start with a failing test, make the test pass, refactor and repeat.

I don’t think I have ever been very strict about the TDD workflow. I usually jump back and forth between the code and the unit test, often begin with trying out naming of functions and less-important things like that. I also find refactoring difficult at that stage, probably because the goal is to write code that does something and that does it well enough. I find it much easier to reflect and come up with refactoring ideas once I see a Pull Request diff on GitHub.

Too much context switch

Until recently, I have failed to find a workflow that is seamless when writing, running and testing code. There is often context switching involved: executing commands that run tests in a terminal or navigating the test runner of an IDE. Sometimes that means a pause with a delay of seconds, or even minutes. The eyes and the brain have lost attention to the code. The focus and flow is gone. Now where was I?

What would Clojure do?

These days, the programming language that makes me 🤩 is Clojure. It has been quite a journey learning how to use the language and how to use the code editor properly. I guess most of us don’t pick up all the good parts of a language or a tool immediately. It takes a while to get there.

An example: my brain hasn’t had the bandwidth enough to get how to use the interactive REPL until recently. There has been a lot of other things to unpack: language syntax, functional programming concepts and keyboard shortcuts. On a positive note: there are opportunities for daily learning and that’s where I am today.

- Wow, I can evaluate an expression in the code editor and the result pops up right next to it!

Star struck. 🤩

The other day I was frustrated with the slow feedback from a CLI test command running in a terminal window. I guess it has something to do with the Java Virtual Machine starting up every time a command is executed. I’ve tried out tools with file watchers, reacting to changes, that speed things up - but there’s still context switching involved, moving your eyes off the editor & the code.

What would a Clojurist do? I think the answer would be:
- Use the REPL.

The REPL, you must use

With Clojure, using the REPL means writing code in the editor, with autocomplete and everything. Also, evaluating the code while in the editor. There is no need to write a statement in a separate terminal window. Your editor has a connection to the interactive REPL (a running server), that will evaluate your code and return the result back to you. With the interactive REPL, you can quickly try things out, without switching to a different tool or view.

This is what some people call REPL Driven Development. Before I learned about it, I have always thought of a REPL as something that is used in a terminal window, away from the editor and away from the code.

Development Deluxe

By combining REPL Driven & Test Driven Development we have a setup that solves the issues with context switching and slow test runs. From what I’ve learned and tried out so far, I think it is a very nice workflow. 🤩

A very nice workflow

With REPL Driven Development, you write code, evaluate it and get instant feedback while keeping your focus on the code. Maybe the quick visual feedback in the editor is good enough to continue working? Great. Or, you write one or two commands wrapped in a runnable Clojure (comment) block just below the functions, to simplify the evaluation.

Everyone needs a coffee break. Commit the code (yes, the commands too) and continue with it later. ☕

Take a break

Your brain has been charged and you feel refreshed again. When returning to the code, you realize that the commands are probably evolving into something similar to a unit test. Should it be a proper unit test? If so, wrap it in a (deftest) function with some assertions and put it in a separate file.

Here’s a tip: give the unit test the same namespace as the actual code, but add a -test suffix to it. When doing so, your code editor (if it is smart) can run the corresponding tests when in a namespace. If you are an Emacs user, simply press the keys C-c C-t n to run the tests.

Even though you have put the unit tests in a separate file, in a separate folder, there is no need to switch context. Your tests run from where you are and you get instant feedback on the result. Very cool.

I think this is Test Driven Development Deluxe. 🤩

☕

<sup>Photo by Felipe Giacometti on Unsplash.

The screenshots are from email-attachments - A Clojure library that makes extracting attachments from email simple.</sup>

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.

Test friendly JavaScript modules - without Dependency Injection

A while ago, I was trying to figure out how to use test driven development with ES2015 (also known as ES6 at the time). It turned out to be a nice experience, and I wrote a blog post about it: Can I test it?

However, I had some concerns about the import feature and how to deal with module dependencies. I wrote a blog post about that too: Is the ES6 import feature an anti pattern?

Recently, I have been learning Python and was surprised by the similarities with JavaScript - in coding style, philosophy and language features. I guess Python has been a source of inspiration for the new ES2015 stuff. I have quickly become a fan of Python and I think it is a very nice language.

 At first, as a Python newbie, I stumbled upon the same questions on how to unit test modules containing a bunch of import statements. Luckily, at work I am surrounded with great programmers in general, that also are experts in the Python language. With Python, the answer to my questions was both simple and obvious. Python is a dynamic language: load the dependency in the unit test, then just override it. The code under test will use the already loaded in memory module. Simple, huh? It seems to me that there is no need for c#/java like dependency injections. I guess it was my typed language mindset that had guided me to IoC and DI patterns.

What about JavaScript?
I think it is (almost) as simple! Modules and imports in JavaScript are similar to (but not exactly like) the Python way. In JavaScript, I guess it also depends on the module loader used in the current environment. I have experimented with this. My setup contain ES2015 modules and unit tests, that are transpiled with Babel to RequireJS modules, runs in a browser or with PhantomJS. With this setup, I have managed to override module dependencies with fakes from a unit test. The module under test will actually run the fake dependency, and there is no need for custom Dependency Injection.

An example: a unit test
import foo from 'modules/foo';
import bar from 'modules/bar';

const fakeMessage = 'a fake message.';

const original = bar.getMessage;
const fake = () => fakeMessage;

QUnit.module('my example tests', {
    beforeEach() {
        bar.getMessage = fake;
    },
    afterEach() {
        bar.getMessage = original;
    }
});

QUnit.test('can an imported module be mocked?', assert => {
assert.equal(foo.message(), fakeMessage);
});

And the actual code under test:
import bar from 'modules/bar';

let foo = {
    message() {
        return bar.getMessage();
    }
};


export default foo;

I would appreciate your feedback on this!

You will find unit tests, code, settings, project structure and setup at my GitHub page:
https://github.com/DavidVujic/blog/tree/master/es2015-testable-modules

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)

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.

ES6 & TDD: Can I test it?

(Yes you can!)

I like the style of Test Driven Development (TDD), dead or not. I have been using TDD mainly for server side code with C# and NUnit. I think the benefits of writing unit tests for client side code is obvious. Now, with ECMAScript 6 (ES6), we have cool stuff like modules, promises, iterators ... is ES6 testable?

Interested in test driven JavaScript in general? Check out From the Streets of Test Driven Development: JavaScript.

Write, transpile, test?
To use all those cool new JavaScript features today, the source code need to be transpiled to a version that browsers support. What about the unit tests (that is also written in JavaScript)?

The unit tests can (of course) be written in old school JavaScript (ES5). But I think the context switch between the two (ES5/ES6) probably would break the flow. I would like to write both the unit test and the code in ES6. How about using Babel to transpile them both?

Check out my earlier post about some tools I use (like Babel): Sublime ES6 coding - the tools and the flow

QUnit and ES6 arrow functions
I like the simplicity and the basic TDD style of QUnit. I like the words test and assert. Jasmine and Mocha are cool to, using the behavior driven style of writing, but I prefer the classic TDD approach. Maybe it's a mindset thing? 

QUnit uses a test runner, that is where the unit tests are started. The test runner is an html file and lives in a browser (or in PhantomJS). That's the old school world. Transpiled versions of unit tests and transpiled production code will run there. There are some things to think about. QUnit doesn't identify itself as a loadable module (yet). Instead, a variable is added to the global object. By default, QUnit will run when the DOM is loaded. When used with AMD, QUnit have to be paused until the unit test modules are loaded. In this example, I have transpiled ES6 code to AMD modules (RequireJS) using Babel. The test runner is loading a single file that will import all my unit tests.

You will find unit tests, code, settings, project structure and setup on GitHub: 
ES6 and TDD

Example - the script section of the test runner html file, written in old school JavaScript:
(function () {
  'use strict';

  QUnit.config.autostart = false;
 
  require(['script/transpiled/start.js'], function () {
    QUnit.load();
    QUnit.start();
  });
}());


The contents of start.js, importing all unit test modules, written in ES6:
import {} from './modules/exampletest.js';


The unit test, written in ES6:
import foo from 'modules/foo';

QUnit.module('my example tests');

QUnit.test('will this work?', assert => {
     const expected = 'hello foo';

     assert.equal(foo.message, expected);
});

The code under test, written in ES6:
let foo = {
     message: 'hello foo'
};

export default foo; 

The require and imports of the test runner and start.js uses relative urls. That is because I use the same base url as the production code. This enables the simple kind of imports done in the unit test. The code there is written in the same way it would in the production code.

Run with Gulp 
I use Gulp to automate a lot of things: transpiling with Babel, checking for syntax errors with JSHint and running QUnit tests with PhantomJS (i.e. no browser required). All of these will execute as soon as any ES6 file is changed in my project. By doing that, I will get instant feedback without having to interupt the flow.

Give the code a try and let me know what you think about it. What aspects am I missing? What can be improved, changed, refactored?

You will find unit tests, code, settings, project structure and setup on GitHub: 
ES6 and TDD

Is the ES6 import feature an anti-pattern?

The new version of JavaScript is currently occupying my mind. I really like the ECMAScript 6 features, and the fact that we can write code using new stuff like arrow functions, scoped variables and native modules today (by using transpilers) is quite awesome.

There is especially one of the ES6 features that I've been thinking about: importing of modules. Modules will change the way we think about JavaScript for the web. Importing a module is so easy with ES6 and the syntax is very nice, readable and clean. How do I unit test such a module?

-----------
Update: I have experimented with an alternative to the examples in this blog. Have a look at it and please share your thoughts and feedback on the different approaches to unit testing modules:
Test friendly JavaScript modules - without Dependency Injection
-----------

The import statement uses a relative url to perform the module lookup. So, can I somehow configure a "base test suite url" to load fake modules that my module under test is dependent of? Would that require me to write a lot of stubs (files)? Is it even possible, without writing a custom module loader? That's the things I have had on my mind, for a couple of days now.

See, these days I mostly think about code and don't actually write code that much. How come? I am currently enjoying life as a swedish dad on paternity leave. The days with the one year old are great. We read books, build with blocks and laugh a lot. I love it.

When he is sleeping, I catch up on coding by reading blogs (mostly one of the great posts on ES6 by Dr. Axel Rauschmayer) or watching a video tutorial (I recommend the ES6 course on Pluralsight, by Scott Allen and Joe Eames). I am learning new things, slowly, but scheduled and at a steady pace.

Tonight, just when I had finished reading a Pippi Longstocking bedtime story to our four year old son (the big brother), the background process of the brain suddenly sent me a message: keep it simple. Use dependency injection. Dave, you know this already. I think the new syntax and the new ways of writing has blinded me, made me forget about concepts I normally use when writing c# or old school JavaScript (pre ES6).

How about writing modules with dependencies injected, by exposing something like an "init" function, instead of directly importing them? That would make them testable. Something like this:

// foo.js
let message = 'My name is foo';

var foo = {
    getFoo() {
        return message;
    }
};

export default foo;

// bar.js - dependent on foo.js 
let message = '';

var bar = {
    init(obj) {
        let foo = obj.getFoo();
        message = `${foo}bar, and I am foonky`;
    },
    getBar() {
        return message;
    }
};

export default bar;

//app.js
import foo from 'modules/foo';
import bar from 'modules/bar';

// inject dependencies
bar.init(foo);

console.log(bar.getBar());

 
Please let me know what you think about it!

-----------
Update: I have experimented with an alternative to the examples in this blog. Have a look at it and please share your thoughts and feedback on the different approaches to unit testing modules:
Test friendly JavaScript modules - without Dependency Injection

-----------

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/