Your SlideShare is downloading. ×
Automated Testing Of EPiServer CMS Sites
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Automated Testing Of EPiServer CMS Sites


Published on

Published in: Technology

1 Like
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. Automated testing of EPiServer CMS sitesAn overview of testing in general and specifically EPiServer sites
  • 2. 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
  • 3. Agenda
    The importance of automation
    Types of testing
    xUnit testing
    Isolating code
    Challenges when testing EPiServer sites
  • 4. The importance of automation
    Quick feedback loops
    Less debugging
    Limits the human factor
  • 5. 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.
  • 6. Types of automated tests
    UI Tests
    Integration tests
    Unit tests
  • 7. 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
  • 8. 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
  • 9. 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
  • 10. The common name for a set of code-driven testing frameworks
    Test Fixtures
    Test Suites
    Test consists of four phases
    Set up
    Tear down
  • 11. 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
  • 12. 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
  • 13. 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
  • 14. 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
  • 15. Inversion of Control – An example
  • 16. 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
  • 17. The consumer of the consumer provides the consumer with the component it depends upon
    Constructor Injection
    Property Injection
    Dependency Injection
  • 18. The consumer retrieves the component it depends upon from a third party, a Service Locator
    Use Dependency Injection instead if you can
    Service Locator
  • 19. Frameworks for managing dependencies
    Enable life cycle aware applications
    A wide range of open source frameworks
    Castle Windsor
    IoC Containers
  • 20. 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
  • 21. 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
  • 22. Create wrappers
    Beware of security concerns
    Overcoming static and non-virtual methods
  • 23. Create wrappers
    Use Page Type Builder to decouple from PageData.Property
    Partial mocking
    Overcoming dependencies on the configuration
  • 24. 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
  • 25. Model View Presenter
    Image from
  • 26. 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
  • 27. 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
  • 28. 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
  • 29. 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
  • 30. Questions?