Thanks for sharing some of these ideas.
Joe Fraley

For the Page Object pattern, look at Martin Fowler’s write up. I have yet to see a tool that applies it well in a generic way. The state of practice is that you create it yourself with tool and framework support. For example, in Ember’s highly opinionated framework, it’s much easier to create a passable page object assist than it is for something with unconstrained scope like Selenium. At least right now, this isn’t something you’re getting out of the box in general and Selenium in particular has had some issues dealing with SPAs. The example you gave is common, but I agree not very useful.

I apply the Page Object pattern at a component level, perhaps for a collection of components if they’re meant to work together. This gives you a higher level DSL with which to compose tests. The testing of the components means your higher level tests only need to verify the interactions that are essential to their use together. That lower level of coupling makes your tests less brittle.

As for the churn, hopefully you know what you’re trying to achieve and what’s no longer desired with each of those churns. That’s your list of tests to write, delete and update. You’re the one turning the crank, or at least working with your designers, product people, etc. to turn it.

We’d probably have to sit down with a site to really answer your questions concretely. At the highest level of tests, though, they should read like you would describe what the user is doing to your grandmother. She knows, “Select an account, enter a payee and an amount, and submit the payment,” not “Choose the option with ID 645 from the dropdown, type s-o-n-tab in the mbas_target_payee field, ….” The page object and other abstraction layers bridge the gap and encapsulate the fiddly details like async behaviors, finding the meaningful controls in the page, interaction details, etc.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.