2

The company I work for is starting a new web application, and I have requested that front end developers make this application Automation Friendly.

The previous application was using the react framework, very few elements had unique ID's (or any unique identifier at all). This time around, I have asked the developers to include a custom data attribute, specifically for automation.

I am looking for anyone who may have experience in this kind of situation.

  1. What have you asked your developers to do to assist in automation?
  2. Are there any standards, or guidelines for naming elements in an application to suit Selenium automation?
  3. are custom data attributes the best way to go? are there other options?

Any advice/guidance would be greatly appreciated!

undetected Selenium
  • 183,867
  • 41
  • 278
  • 352
Luke676
  • 65
  • 10
  • custom data attribute is good option – Pritam Maske Feb 28 '19 at 18:55
  • 1
    I write automation for a number of sites and they have not added anything special to the elements to aid with automation and we've had no problems writing automation for the sites. I would suggest you study up on CSS selectors and XPaths. Once you learn the basics (and maybe a little more), there's really not much you can't locate. If you have specific examples of elements that you can't locate easily, post a few and we'll help write locators and/or teach you some tricks, etc. – JeffC Mar 01 '19 at 04:22
  • I agree with @JeffC. If you know how to create locators and use them, it becomes compartively easier to locate elements. – demouser123 Mar 01 '19 at 08:22
  • I understand what you both have said, and I have done that for the passed year. Upper management wants these elements added to the front end. The way I look at it, I have no reason to argue with them, as it would only benefit the automation team. – Luke676 Mar 01 '19 at 13:23
  • 2
    As a developer for 37 years who has been doing automation for the last three, thank you for posting this. It's been forever since I was in college, so I doubt anything like this is taught in school, but it needs to be. – Bill Hileman Mar 01 '19 at 21:14

2 Answers2

2

Web Applications can be difficult to test if they aren’t made with testing in mind. This is especially true for Single Page Applications (SPAs). SPAs support heavy interaction without incurring additional page loads (e.g. Facebook, Gmail). Instead of page loads, these SPAs use AJAX requests to relay data back and forth from the server.

As per @ChrisChua from ThousandEyes these are some of the best practices to keep in mind as you develop your web application to make testing easier:

  • Add classes that are meaningful.
  • Classes should indicate the element’s functionality and state.
  • Use functional names in IDs and classes for action elements.
  • Dynamically generated classes and IDs are not helpful for testing.
  • Add targetable DOM feedback to indicate application state.
  • Never hard-code content in test code!

Conclusion

It's true some of these are not easy changes, as the developer may have to think harder about using test-friendly designs rather than "something that just works". However, it will definitely help with maintainability of the testing, which would reduce costs in the long run.

tl; dr

A couple of references:

undetected Selenium
  • 183,867
  • 41
  • 278
  • 352
0

Test Driven Development makes it easier to automate. In my opinion, testers should be developers, or ex-developers who are good at finding and preventing mistakes. Write the tests in the same project that the solution is being developed in. Developers can also put in ids, even though they don’t want to sometimes, and if the “testers” are good they can even submit pull requests (in GitHub for example) for code improvements that will allow them to test better. Think of testers as a piece of your development team, where everyone is allowed to contribute code. It helps with accountability and improves autonomy. Everyone is there to help each other and if all the code is in the same project, and all code is reviewed and approved before merging to master, everyone is a potential developer if everyone is IT. The old days of manual testing are dying. Separating Dev from Testing is a brick wall. Tear it down.