Joel Spolsky famously wrote in 2002 that “All non-trivial abstractions, to some degree, are leaky.”
This of course doesn’t mean that abstractions are bad – in fact we wouldn’t be able to do anything non-trivial without them – but instead that we need to understand the underlying mechanism to be able to use the higher level concept.
Over the years I’ve created many frameworks and abstractions for UI test automation, for both coders and non-coders alike. Looking back, were these good or useful abstractions? How leaky were they and what were the consequences for users of these abstractions?
If you’re just starting out on your automation journey, how would having this knowledge affect how you write tests and what those tests look like? What about if you are using APIs like Selenium, or frameworks that have been created on top of Selenium? What leakiness exists, and how much do you need to know, regardless of the abstraction in place?
Join me as I take you through some lessons learnt, patterns and approaches that have personally been successful, and some observations on current trends in relation to abstractions and knowing your automation.
Sli.do – V231