Used My IDE a LOT…Kinda Like a Dev
My IDE was up a majority of the time this past week, like I’ve never used it before. As I’m becoming more comfortable with coding, I found myself It didn’t dawn on me until Friday afternoon, when I looked at the developers that sit proximity to me, that I felt like one of them. Sure, I was testing, but I was coding as well. And it felt damn good!
Used Automation Guild Slack Channel for Newbie Question
As a newbie to automation, I stumbled upon a scenario in which I had multiple h2 elements on one page. My questions on the Automation Guild Slack Channel were:
- “Would you recommend I make one assertion test on this one page with multiple h2 elements?” or
- “Would you recommend I break these out into individual tests?”
Here’s the feedback I received:
“1 Test, 1 Validation… This makes reading and understanding what the test is doing more clear…If you begin combining a bunch of test into what looks like one validation step, you add efficiency at the expense of maintainability…”
“You can use a data factory to use the code from one test to assert each of them separately though to make your life easier”
I’m a context guy. If the scope of the test is that a page has several un-named / non-purposed H2s, go for basic. If each are called out with specific purpose – I’d target each one. As @gregpaskal and @lazycoder are hinting – there certainly is a benefit to handling all of them at once. But even when handling them all at once you can have a series of assertions in your one test (presume a selenium/unittest framework basis) (so short story – 1 ‘test’, likely multiple targeted assertions.
“Breaking you tests up into the smallest chunks possible is always desirable. Even if all of your tests have to log into their own separate space before getting to the part of the application they are testing, once they are set up, they can be run in parallel. As long as the system can handle a large volume of users, this will save lots of time despite the duplication.
As for finding specific elements on the page, there are a couple of ways to go about this. The first is to ask your developers to assign unique id’s or names to the elements you care about. Id’s are more preferable because they are quicker for Selenium to find, but a unique name field will also work. This is preferred as it means that if the element you are looking for is moved to another part of the page, it can still be easily found.”
If you have opinions or advice this topic, please feel free to leave comments. All I ask is that you be respectful.
Read “Fifty Quick Ideas to Improve Your Tests” by Gojko Adzic
“Fifty Quick Ideas to Improve Your Tests” by Gojko Adzic, was a book recommended by Meaghan Lewis on Test Talks Episode 126. The book is broken up into, you guessed it, “Fifty Quick Ideas to Improve Your Tests.” Each idea has a real-life example of a problem with a proposed solution, key benefits of the proposed solution, and finally, how to implement the solution. It’s a very quick read and includes some helpful hints as to designing tests, designing good checks, etc. What I really liked about it though is that it brings to light some of the habits that one (me) would plan and design for a manual test versus what is recommended for an automated test. It’s a book I see myself referencing back to from time to time, for perspectives from encounters in automation I’m bound to encounter. You can pick up the book on LeanPub or Amazon.
Subscribed to the “Whiteboard Testing” YouTube Channel
I was curious about “Whiteboard Testing” by Richard Bradshaw the Boss-Boss of Ministry of Testing, so I began watching a few of the episodes, and really enjoyed it. I’m currently on “Lim Sim’s Response to the F.A.R.T Model” the acronym for Flawed Approached to Regression Testing.
Greg Paskal’s Advice
Greg Paskal provided some additional advice to me earlier in the week which was:
“As you are getting you mind around test automation, now is a great time to form some awesome habits. I want to encourage you, when building locators to not base them on anything related to the look and feel of an application. From my experience, look and feel attributes are typically the most dynamic part of an application and will add unnecessary maintenance to your automation efforts. Items such as CSS Class are great examples of locator attributes to avoid. There are exceptions to this rule, sometime developers don’t include ID tags or other non-UI based attributes and they are unwilling to put them when you ask. Only under these conditions should you turn to Look and Feel attributes for locators. I can assure you, this habit will lead to more solid test automation that will require less maintenance in the future.
xPath has really been given a bad rap. Most examples online are really poor and have come from folks using a record and playback approach to building automation. I’ve got a surprise to share, xPath is actually the key to building some of-the best locators possible when it comes to Selenium development. The reason why? Because xPath locators can be debugged using Developer Tools built into Chrome which means you can build and tune testable locators before you ever build them into your script. It also means when a locator is acting up, you now have a tool to troubleshoot your xPath locator with a trial and error approach by inserting it within you code and then running it to see if it solid or not.”
Resumed reading “Java for Testers” by Alan Richardson
“Java for Testers” by Alan Richardson continues to be a great book as to how to apply Java to testing. With each chapter, I’m picking up something new. Again, I’ll provide a more in-depth review once I’ve completed the book. If you can’t wait and would like to pick it up now, on Amazon or by going to http://eviltester.com