...

Here's the typical testing pyramid - it clearly shows that UI tests will not replace any other tests (manual tests or Acceptance (Integration) tests).

UI Tests

For now we'll use Selenium for testing our ui. Test will be part of magnolia-integration-test and use its test-webapp & test-public-webapp (much as the integration tests do)

Goals

Have few typical cases automatically covered to prevent regressions there.

1. Basic Content App test (use Contacts App as it's a simple example)
   
   • navigate to Contact App, open a contact in a tab
   • edit (modify), save, close
   • verify tree is updated
     
     
2. Bookmarking (use Contacts App again)
   
   • open new default subapp
   • navigate to opened default sub app
   • open new non-default subapp - verify default subapp is also opened
   • navigate to opened non-default sub app
     
     
3. Activation
   
   • verify basic activation works - no workflow
   • LATER (when workflow is ready): verify activation with workflow
     
     
4. Test Pages App

• • Test basic Page editing

Design

Next steps

• integrate with ordinary integration tests to re-use it's setup in pom
• complete once demo-project can be added to test web apps
• test will go into magnolia-integration-test/uitests in ce-bundle
• test will be executed using Firefox as this one has a headless mode

Outlook

• Execute tests with with different browsers (Firefox, Chrome, Safari, Ie, ...) an different OS's (OSX, Unix, Windows, iOs, ...) using hudson slaves

...