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