Another day, another San Francisco Selenium Meetup :).
Tonight’s venue is Walmart Labs, and as a special treat, I finally get to attend a MeetUp close to home (Walmart Labs is right here in my home town of San Bruno, CA).
This will be presented in live blog format, which means, as usual, it will be updated regularly throughout the evening. Click refresh to get the most recent updates. If you see “End of Updates” at the bottom of the post, you’ll know the live blog has concluded. I’ll be picking up with the real topic in just a bit.
UI testing in Java – How, When and Why
General Abstract from Meetup.com
Mathilde Lemae Bio
After being a freelancer for many years, Mathilde Lemee joined Software AG (Terracotta) in 2012 as a R&D engineer in Java, working on ehcache and bigmemory. She co-founded the Duchess France Chapter, an organization to connect and give visibility to women in Java technology, in 2010, where she organized a lot of events (Hadoop, Mahout, Mockito, Cache …). She blogs on http://www.java-freelance.fr about performance, best practices and testing. She is a regular open source commuter and creator of FluentLenium, a wrapper around Selenium that provide a Fluent API which is used in other open source projects, like Play!2. She is a regular speaker at various Java conferences in Europe (Paris JUG, Devoxx France, Mix-it, Softshake) and she’s also a mobile educative game editor (http://www.aetys.fr) on iPad/iPhone and Android.
After a bit of a pitch from WalMart Labs about their current offerings and job openings (yep, they’re looking for people both on the coding and testing side, if anyone’s looking).
A number of examples are being shown to demonstrate the syntax and ways that FluentLenium can add options such as searching, filtering, regular expressions etc. The idea is that native Selenium/WebDriver is always available, but FluentLenium add a number of additional commands and structured statements that are meant to more naturally express statements.
One of the nice features described is the fill option, which is designed to work directly with forms. While the statement isn’t much shorter, the actual syntax is clean and easy to read. It’s a nice step towards self documenting code, at least as presented. Yes, it’s still Java, but it’s cleaner and nicer than a lot of the Java code I’ve seen (or written ;)… pictures will be posted in a bit).
Mathilde demonstrated how she has made a wrapper to support page object patterns as a way to tame over-exuberant Java expressions. Again, I’ll give her credit, the code is easy to follow as written. It feels deceptively easy, but more to the point, it kind of reminds me of Capybara as it relates to Selenium. Not an exact parallel, but hey, I calls ’em as I sees ’em.
An interesting method that Mathilde demonstrated is called await. This is a nice and compact way to ask an app to wait for an element to appear. Again, I give props for the ease of reading, and the intuitive nature of the statements.
There’s a nice addition called @SharedDriver, which allows for the WebDriver object to be launched just once and shared among tests. That alone can be a huge time saver. Shared Driver can also be allocated per class or per method. It’s up to you.
For those who are used to using Cucumber and Gherkin, yes, FluentLenium supports it. FluentLenium allows for creating step definitions using the syntax and methods. Here the similarity with Capybara is even more apparent.
Overall, this looks like an interesting tool. I’d be interested in seeing some more examples and playing around with it some. Having said that, I do worry that an over-dependence on abstraction tools, no matter how pretty or easy to read, has the potential to add more problems than it solves. First, FluentLenium is based on Java, so you have to use the Java bindings and test structure to use it. Second, Java has enough syntactical weirdness at the ground level. For me, I know there’s plenty of aspects of the native Java language bindings I need to get more proficient with. After I exhaust those options, or I find myself wishing I could do other thin
gs beyond what the base Java bindings provide, then I could see this being both valuable and interesting.
End of Session.