Automated testing of EPiServer CMS sites provides an overview of testing approaches for EPiServer sites. There are three main types of automated tests: UI tests, integration tests, and unit tests. Unit tests are the fastest and provide the most precise feedback by testing individual units in isolation using mocking frameworks. While challenging due to EPiServer's static methods and tight integration with Web Forms, unit testing can be achieved by creating wrappers and extracting business logic using patterns like MVP. The document provides advice on best practices for unit testing EPiServer sites.

1. Automated testing of EPiServer CMS sitesAn overview of testing in general and specifically EPiServer sites

2. About meJoel AbrahamssonLiving in StockholmWorks at ValtechDevelops websites with ASP.NET and EPiServerBlogs about web developmentFounder of the open source projects Page Type Builder, EPiAbstractions and co-founder of EPiMVP

3. AgendaThe importance of automationTypes of testingxUnit testingIsolating codeChallenges when testing EPiServer sites

4. The importance of automationQuick feedback loopsLess debuggingLimits the human factorDocumentation

5. Automation goalsWe want our tests to be run. Often. By everyone.Tests should be self-checkingTests should be repeatableTests should be independent of environmentTests should run fastThere should be no hassle running our tests.

6. Types of automated testsUI TestsIntegration testsUnit tests

7. UI TestingTests all layers of the applicationFrameworksSeleniumWatin/WatirCan be run using a GUIor as part of xUnit testsProsConcrete/easy to understandEasy to get startedConsVery slowHard to maintainBlunt feedbackUse for a few key scenarios or when refactoring for testabilityWrite maintainable tests using Page ObjectsUser interfaceBusiness logicData accessDatabase

8. Tests several layers of the applicationImplemented using Xunit frameworksProsNo isolation requiredEnsures that whole features workConsSlowDoesn’t give very accurate feedbackHard to maintain and set upUse to verify functionality of interactionsDon’t confuse with unit testsIntegration TestingUser interfaceBusiness logicData accessDatabase

9. Tests individual units in the systemImplemented using Xunit frameworksProsFastPrecise feedbackCan be used to drive developmentand ensure good designConsRequires isolation/mockingUse to drive development to ensure good design and provide documentationWrite tests for design and documentation, not quality assuranceUnit TestingUser interfaceBusiness logicData accessDatabase

10. The common name for a set of code-driven testing frameworksTest FixturesTest SuitesAssertionsTest consists of four phasesSet upExerciseVerifyTear downxUnit

11. The verification phase consists of one or several assertionsTests either test state or interactionsVerifying state means checking a returned value or ensuring that an object is in a specific stateVerifying interactions usually means verifying that the component being tested has performed an interaction with another component. xUnit - Asserts

12. FrameworksNUnitMBUnitxUnit.netVisual Studio Unit Testing Framework / MSTestExecuted using test runners on clients and by build serversMany frameworks comes with built in runnersResharperTestDriven.NETxUnit Frameworks

13. Replace a depency with a different component with the same interface to enable and verify interactionsAlso known as mockingAccomplished using Inversion of ControlReplacing interface methods or virtual methodsFrameworksRhino MocksMoqIsolatorNUnit.MocksCode Isolation

14. Allow a consumer to consume a component without knowing the specifics and origins of the component in advanceImplement using Dependency Injection or Service LocatorInversion of Control

15. Inversion of Control – An example

16. Using IoC leads to flexible componentsUsing IoC helps us conform to the SOLID principles The Dependency Inversion Principle - Depend on abstractions, not on concretionsThe Single Responsibility Principle - A class should have one, and only one, reason to changeIoC leads to good design

17. The consumer of the consumer provides the consumer with the component it depends uponConstructor InjectionProperty InjectionDependency Injection

18. The consumer retrieves the component it depends upon from a third party, a Service LocatorUse Dependency Injection instead if you canService Locator

19. Frameworks for managing dependenciesEnable life cycle aware applicationsA wide range of open source frameworksStructureMapNinjectUnityCastle WindsorAutofacIoC Containers

20. Test DoublesDummies – objects that are passed around but never used.Fakes – Working implementationsStubs – Provides implementations for certain methods with responses defined in the testMocks – Same as stubs but with expectations that can be verifiedPartial mocksIsolation/Mocking terminology

21. Static or non-virtual methodsExample: all methods in DataFactory are non-virtualMakes Inversion of Control hardDependent on it’s configurationMakes it hard to test single units of codeTightly integrated with Web FormsMakes it hard to test without a HTTP ContextComplicates Depency InjectionEPiServer CMS challenges

22. Create wrappersEPiAbstractionsepiabstractions.codeplex.comBeware of security concernsOvercoming static and non-virtual methods

23. Create wrappersUse Page Type Builder to decouple from PageData.PropertyPartial mockingOvercoming dependencies on the configuration

24. Extract business logic from pages and controlsUse Page Type Builder to decouple from PageData.Propertypagetypebuilder.codeplex.comThe Model View Presenter patternWeb Forms MVPwebformsmvp.comEPiMVPgithub.com/joelabrahamsson/EPiServer-MVPOvercoming tight Web Forms integration

25. Model View PresenterImage 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 EPiMvpUserControlA base class for presenters, EPiPresenterA presenterfactory that instantiates presenters for views with the view and PageData objectAlso comes with two presenterfactories that utilizes IoC containers, StructureMap and NinjectEPiMVP - Components

27. A request comes in to the viewWeb Forms MVP inspects the views PresenterBinding attribute to find the presenter typeWeb Forms MVP uses a configured (in global.asax) PresenterFactory to instantiate a presenter with a modelobjectThe presenter, which receives the view and PageData object in the constructor attaches it’s methods to the view’s eventsEPiMVP – How it works

28. Good candidates for testing includeIntegrations with external servicesUtilities (AddQuerystringParameter etc)Custom cachingComponents that easily get to be complex (example: paging)Bad candidates includeComponents with extremely little logicComponents 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 designWhat to (not) test using unit tests

29. Give your tests descriptive namesCare about the code in your testArrange your tests using AAA (Arrange, Act, Assert)Also known as Given-When-ThenBe carefull with using code coverage as a measurementSome principles such as the DRY principle isn’t always valid for testsDo not use tools to generate tests. Period.Words of advice

30. Questions?http://joelabrahamsson.com@joelabrahamssonmail@joelabrahamsson.com