To automate, you have to code. And if you are automating an application, the logical way to think about it is developing an application to test an application. And to do that from scratch – every time – would be laborious, and unnecessary as there are many common web features. This kind of thinking has been around in software development for decades – to program with reuse in mind. But because of short term thinking especially prevalent on web projects, it is more about getting site live as quickly as we can get away with it. But that doesnt mean testers have to have same approach to developing test automation. On the contrary, it serves testing better to have design pattern approach, as testers rarely work on one project for too long, and generally have two or more projects to juggle. Also one of the biggest risks is testing with no real value, because it is duplicated or simply irrelebvant. So what could be resued? Well, any test automation of forms has potential for reuse, probably the easiest one for people to understand. A form is a set of fields and action button(s). Forms generally expect some kind of identity of form author and contact details.
Page Objects are a good way to apply design pattern approach to BDD test automation, i.e. separating services from design. As much of test automation can happen “under the hood” with headless browsers, following this practice is sensible, and will help the developers focus on coding what they actually need to, without acceptance tests being cluttered with design information. This is in no way devaluing design, but design is a mask for functional code behind it, and in the course of development it is important not to muddy design issues with coding issues.
We have moved far away from the clunky third-party monstrosities that plagued early test automation. These were the applications to test applkications, but they rarely did what we needed them to do, and quickly became full-time jobs in themselves. Painful, in hindsight. Not that the myriad of open source test tools are a picnic – you have to want to learn an enjoy it, or forget it – test automation is not for you. You could go really “down and dirty”, code testing apps yourself, but perhaps too masochictic for most! For myself, I am building my core skills in php and a selection of tools such as behat, selenium, mink, phantomjs, zombie js. Why I am always loved opensource world so much is the specific tools for specific jobs, not pretending to be the “all in one solution”. That’s ridiculous and a plain sales lie. BDD offers a more realistic route to test automation with true value to both development and client.
In the future, there will be more language-driven coding possible, but for now we can create this to a degree, as many web actions are common. But it doesn’t simplify programming, it opens up possibilites – it’s important to think about newer programming methods that way, and not to make it easier. The more we move towards the next generation(s) or programming, the more development and testing will merge. At the moment, I use Behat as my BDD tool of choice, though all appear to use same specification language (Gherkin). There is a variety of test runners to choose, depending on what you want to test, and how. I will delve into this more in another post. The most important part of BDD is maintaining the trace from user stories and scenarios, through to code – it sounds simple, but everyone on the team has to observe the process for it to succeed.