Automated testing of EPiServer CMS sites

An overview of testing in general and specifically EPiServer sites

About me

• Joel Abrahamsson• Living in Stockholm• Works at Valtech• Develops websites with ASP.NET and EPiServer• Blogs about web development• Founder of the open source projects Page

Type Builder, EPiAbstractions and co-founder of EPiMVP

Agenda

1. The importance of automation2. Types of testing3. xUnit testing4. Isolating code5. Challenges when testing EPiServer sites

The importance of automation

• Quick feedback loops• Less debugging• Limits the human factor• Documentation

Automation goals

• Tests should be self-checking• Tests should be repeatable• Tests should be independent of environment• Tests should run fast

We want our tests to be run. Often. By everyone.

There should be no hassle running our tests.

Types of automated tests

• UI Tests• Integration tests• Unit tests

UI Testing

Database

Data access

Business logic

User interface

• Tests all layers of the application• Frameworks

– Selenium– Watin/Watir

• Can be run using a GUIor as part of xUnit tests

• Pros– Concrete/easy to understand– Easy to get started

• Cons– Very slow– Hard to maintain– Blunt feedback

• Use for a few key scenarios or when refactoring for testability• Write maintainable tests using Page Objects

• Tests several layers of the application• Implemented using Xunit frameworks• Pros

– No isolation required– Ensures that whole features work

• Cons– Slow– Doesn’t give very accurate feedback– Hard to maintain and set up

• Use to verify functionality of interactions• Don’t confuse with unit tests

Integration Testing

Database

Data access

Business logic

User interface

• Tests individual units in the system• Implemented using Xunit frameworks• Pros

– Fast– Precise feedback– Can be used to drive development

and ensure good design

• Cons– Requires isolation/mocking

• Use to drive development to ensure good design and provide documentation

• Write tests for design and documentation, not quality assurance

Unit Testing

Database

Data access

Business logic

User interface

• The common name for a set of code-driven testing frameworks– Test Fixtures– Test Suites– Assertions

• Test consists of four phases– Set up– Exercise– Verify– Tear down

xUnit

• The verification phase consists of one or several assertions• Tests either test state or interactions• Verifying state means checking a returned value or ensuring

that an object is in a specific state• Verifying interactions usually means verifying that the

component being tested has performed an interaction with another component.

xUnit - Asserts

• Frameworks– NUnit– MBUnit– xUnit.net– Visual Studio Unit Testing Framework / MSTest

• Executed using test runners on clients and by build servers– Many frameworks comes with built in runners– Resharper– TestDriven.NET

xUnit Frameworks

• Replace a depency with a different component with the same interface to enable and verify interactions

• Also known as mocking• Accomplished using Inversion of Control• Replacing interface methods or virtual methods• Frameworks– Rhino Mocks– Moq– Isolator– NUnit.Mocks

Code Isolation

• Allow a consumer to consume a component without knowing the specifics and origins of the component in advance

• Implement using Dependency Injection or Service Locator

Inversion of Control

Inversion of Control – An example

• Using IoC leads to flexible components• Using IoC helps us conform to the SOLID principles

– The Dependency Inversion Principle - Depend on abstractions, not on concretions

– The Single Responsibility Principle - A class should have one, and only one, reason to change

IoC leads to good design

• The consumer of the consumer provides the consumer with the component it depends upon

• Constructor Injection• Property Injection

Dependency Injection

• The consumer retrieves the component it depends upon from a third party, a Service Locator

• Use Dependency Injection instead if you can

Service Locator

• Frameworks for managing dependencies• Enable life cycle aware applications• A wide range of open source frameworks– StructureMap– Ninject– Unity– Castle Windsor– Autofac

IoC Containers

• Test Doubles– Dummies – objects that are passed around but never

used.– Fakes – Working implementations– Stubs – Provides implementations for certain methods

with responses defined in the test– Mocks – Same as stubs but with expectations that can be

verified

• Partial mocks

Isolation/Mocking terminology

• Static or non-virtual methods– Example: all methods in DataFactory are non-

virtual– Makes Inversion of Control hard

• Dependent on it’s configuration– Makes it hard to test single units of code

• Tightly integrated with Web Forms– Makes it hard to test without a HTTP Context– Complicates Depency Injection

EPiServer CMS challenges

• Create wrappers• EPiAbstractions– epiabstractions.codeplex.com

• Beware of security concerns

Overcoming static and non-virtual methods

• Create wrappers• Use Page Type Builder to decouple from

PageData.Property• Partial mocking

Overcoming dependencies on the configuration

• Extract business logic from pages and controls• Use Page Type Builder to decouple from

PageData.Property– pagetypebuilder.codeplex.com

• The Model View Presenter pattern– Web Forms MVP• webformsmvp.com

– EPiMVP• github.com/joelabrahamsson/EPiServer-MVP

Overcoming tight Web Forms integration

Model View Presenter

Image from http://geekswithblogs.net/dchristiansen/archive/2007/12/07/microsoft-patterns-and-practices-team-release-the-model-view-presenter.aspx

• Two base classes for pages and controls, EPiMvpPage and EPiMvpUserControl

• A base class for presenters, EPiPresenter• A presenterfactory that instantiates presenters

for views with the view and PageData object• Also comes with two presenterfactories that

utilizes IoC containers, StructureMap and Ninject

EPiMVP - Components

1. A request comes in to the view2. Web Forms MVP inspects the views

PresenterBinding attribute to find the presenter type

3. Web Forms MVP uses a configured (in global.asax) PresenterFactory to instantiate a presenter with a model object

4. The presenter, which receives the view and PageData object in the constructor attaches it’s methods to the view’s events

EPiMVP – How it works

• Good candidates for testing include– Integrations with external services– Utilities (AddQuerystringParameter etc)– Custom caching– Components that easily get to be complex (example: paging)

• Bad candidates include– Components with extremely little logic– Components where the logic is handled by EPiServer (menus etc)– Components that deal with, or are closely coupled to, markup

• Keep in mind that the point of the test isn’t only what it tests but that it drives good design

What to (not) test using unit tests

• Give your tests descriptive names• Care about the code in your test• Arrange your tests using AAA (Arrange, Act, Assert)– Also known as Given-When-Then

• Be carefull with using code coverage as a measurement

• Some principles such as the DRY principle isn’t always valid for tests

• Do not use tools to generate tests. Period.

Words of advice

Questions?

http://joelabrahamsson.com@joelabrahamsson

mail@joelabrahamsson.com