Automated Testing Of EPiServer CMS Sites
Upcoming SlideShare
Loading in...5

Automated Testing Of EPiServer CMS Sites






Total Views
Views on SlideShare
Embed Views



4 Embeds 39 22 7 6 4



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

    Automated Testing Of EPiServer CMS Sites Automated Testing Of EPiServer CMS Sites Presentation Transcript

    • 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
    • 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
      Can be run using a GUIor as part of xUnit tests
      Concrete/easy to understand
      Easy to get started
      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
    • Tests several layers of the application
      Implemented using Xunit frameworks
      No isolation required
      Ensures that whole features work
      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
    • Tests individual units in the system
      Implemented using Xunit frameworks
      Precise feedback
      Can be used to drive developmentand ensure good design
      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
    • The common name for a set of code-driven testing frameworks
      Test Fixtures
      Test Suites
      Test consists of four phases
      Set up
      Tear down
    • 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
      Visual Studio Unit Testing Framework / MSTest
      Executed using test runners on clients and by build servers
      Many frameworks comes with built in runners
      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
      Rhino 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
      Castle Windsor
      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
      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
      The Model View Presenter pattern
      Web Forms MVP
      Overcoming tight Web Forms integration
    • Model View Presenter
      Image from
    • 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?