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 Documentation

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 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

8. 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

9. 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

10. 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

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 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

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 Frameworks Rhino Mocks Moq Isolator NUnit.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 StructureMap Ninject Unity Castle Windsor Autofac 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 EPiAbstractions epiabstractions.codeplex.com 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 pagetypebuilder.codeplex.com The Model View Presenter pattern Web Forms MVP webformsmvp.com EPiMVP github.com/joelabrahamsson/EPiServer-MVP Overcoming tight Web Forms integration

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

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? http://joelabrahamsson.com @joelabrahamsson mail@joelabrahamsson.com