Mathilde Lemee presents a live-demo based session and covers the best practices, patterns and tools that help one deliver a solid web application with Selenium.
Mathilde Lemee is a passionate developer, pragmatic Agilist, testing evangelist and open source committer.
This is a one-of-a-kind conference for application developers, solution and data architects: people who develop business applications, create multi-device aware web applications, process vast quantities of enterprise data, design cloud architectures, and manage high performance infrastructure. The sessions are specifically tailored for Developers and Architects using the popular open source Spring IO Projects, Groovy & Grails, Cloud Foundry, RabbitMQ, Redis, Geode, Hadoop and Tomcat technologies. Whether you're building mission-critical web or business applications, crunching huge amounts of distributed data, or designing the next killer cloud native application, SpringOne2GX will keep you up to date with the latest enterprise technology.
My two cents
I liked of your presentation. Thanks to take time to do that. I will put my two cents about some points.
The test of the test is to see that it had broken (red). It is a good practice to see first that the test is red to after see the test green. I already had problems not following strictly this rule.
Also, we have to treat the quality of the test code as the business code. In your example before the introduction of the Page Object pattern we can see there are duplications. Even if we don´t know about the Page Object pattern we know (or should) that the duplication has to be eliminated in some way. In this case was introducing the Page Object pattern.
The Page Object pattern is a good pattern. Even better if you have no much experience. But you can also only use good code principles to extract abstractions from the duplications and to express better the intent of the test. See more about it here:
Page Objects Refactored
Beyond Page Objects: Next Generation Test Automation with Serenity and the Screenplay Pattern
And also the tests using the Page Objects directly ties them to the user interface workflow. I think it is more appropriate to write them in the bussines rule (funcionality) level. See the following for mor details:
How to implement UI testing without shooting yourself in the foot
That is it. Thanks again.