Today we’ve been doing small workshop dedicated to learning basics of writing functional test using WebDriver with couple of guys from Chernihiv’s Softengi office. The agenda was quite brief

  1. Doing some sort of Prepared Kata. It was Google search page example with entering query and clicking suggestions provided.

  2. Refactoring of code created

  3. Break and retrospection of what had been achieved

  4. More coding to complete the task (checking search results returned by Google)

  5. Quick review of successes :)

Lessons learnt

  • Hell yeah, I know Hamcrest matchers :) and able to use complex combinations of them for assertion, but …​

  • Hamcrest matchers are too verbose for complex collection operation, so …​

  • I’d recommend to write WebDriver tests using Groovy, because it allows better collection processing and other syntax sugar as well

  • KISS principle must be 1st think when designing API. Architect attitude most of the times leads to non required over complication of resulting code.

  • Uncertainty in goals, i.e. tasks definition make people to be bound to pick up very different approaches. Developers need communication and pair working during whole coding process :)

Unfortunately we were out of time, so planned CodingDojo was not done today. But in general we achieved all planned goals: got hand dirty in WebDriver and understanding basic principles of creating tests.

Below are some of retrospection points after 1st phase of workshop, i.e. Prepared Kata. Could be helpful to summarize general approaches while creating WebDriver tests

  • WebDriver tests are about loading pages, finding elements in DOM tree, generating click or input actions and assert changes to DOM tree

  • Usage of PageObject pattern is essential for creating robust and readable tests. Pattern improves code re-usability and encapsulation of DOM structure manipulations. After pattern adoption tests tends to turn themselves into classic BDD given/when/then stories.

  • Page or screen should be considered as a set of services provided to a client and PageObjects should reflect this by using human readable names for method naming

  • Navigation between pages could be represented as returning new PageObject instances while calling method of initial PageObject Web pages are having latency feature. One have to wait before asserting changes made to DOM tree. Especially with high usage of AJAX one always should consider necessity of delays between performing the action and asserting its outcome

  • Waits should be performed using WebDriver’s `FluentWait and WebDriverWait classes, not Thread.sleep(…​) or similar. This reduces delays while running tests making code waiting only when needed for element to appear

  • Tests should assert changes happened to UI. If there’s no changes after some action performed it means either this action is useless and should be removed from screen or screen requires to be adopted for showing a message after action completed

  • Vanilla TDD (tests before code) doesn’t work well with WebDriver tests, but it’s still playing important part

  • Special build scrips should be created for Continuous Integration of WebDriver tests. Scripts should perform checkout, start web server, run tests and stop server