we have a typical web application stack. there are 120 selenium (webdriver) tests that are executed against the application. this takes roundabout 1 hour. we execute them as part of our build chain “compile > unit test > integration test > gui tests”. the gui tests take up a lot of time and we are wondering how to better structure them. currently they are “happy case and unhappy” case tests. they are quite stable i.e. they won’t fail because of programmer errors.
we want to get the build times down and the biggest part are the gui tests. we want to do this based on “customer journeys” i.e. specify (together with the business people) some typical use case and test them (happy path) instead of testing too much…..
how do you guys structure your gui tests? here are some ideas that came to my mind
- only execute happy path tests
- do a “customer journey test”, i.e. do several happy path tests in one (“clicking through the pages”)
- only take the “top 10” specified by the business (mission critical)
- top 10 + “all the rest” as nightly build (one time)
i would appreciate your ideas
thanks
marcel
The nighttime is a perfect time for Selenium tests – you just have to remember to put a “Don’t turn me off!” sticky note on your computer :).
Also, there always is Selenium Grid when the nighttime begins to be too short to run all tests. With Grid, you can run your tests on several machines in parallel!
We have several test suites that are applicable to different situations. Before a major release (to test, to pre-live, to production), everything runs. Usually (on a daily or even hourly basis on rush days) only the “The Quickened Normal Path of a User Through the Application” suite runs. And if somebody “fixes” a large bug, then the tests related to that part of application are run.