Automated Testing Of EPiServer CMS Sites

Automated testing of EPiServer CMS sitesAn 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
The importance of automation
Types of testing
xUnit testing
Isolating code
Challenges when testing EPiServer sites

The importance of automation
Quick feedback loops
Less debugging
Limits the human factor
Documentation

Automation goals
We want our tests to be run. Often. By everyone.
Tests should be self-checking
Tests should be repeatable
Tests should be independent of environment
Tests should run fast
There should be no hassle running our tests.

Types of automated tests
UI Tests
Integration tests
Unit tests

UI Testing
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
User interface
Business logic
Data access
Database

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
User interface
Business logic
Data access
Database

Tests individual units in the system
Implemented using Xunit frameworks
Pros
Fast
Precise feedback
Can be used to drive developmentand 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
User interface
Business logic
Data access
Database

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

A request comes in to the view
Web Forms MVP inspects the views PresenterBinding attribute to find the presenter type
Web Forms MVP uses a configured (in global.asax) PresenterFactory to instantiate a presenter with a modelobject
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

http://www.slideshare.net	22
http://www.valtechlabs.se	6
http://www.linkedin.com	5

Automated Testing Of EPiServer CMS Sites

by joelabrahamsson on Mar 18, 2010

Accessibility

Categories

Upload Details

Usage Rights

3 Embeds 33

Statistics

Automated Testing Of EPiServer CMS Sites Presentation Transcript