TA Basics: Editors, IRB, Developer Tools & Lessons learned

All installations went well so by now you most likely can't wait to start with test automation. And in the next blog post we will, I promise. But I first want to teach you some handy things, give you some background knowledge to you can do it pretty much correct from the beginning.

Editors

It is entirely up to you which editor you use. But some have a few nifty tricks. When I started a little more over a year ago with test automation I just went with Notepad ++. I liked the editor, I knew the editor so it was easy for me to use and to start. A friend of mine has become a fan of RubyMine which is awesome to use since it's build for this purpose, but not free. Recently I found another editor that is free that looks promising and works very nice, Visual Studio Code. Again, I have my favorite, you might have yours, just use whatever you like most, it really does not matter.

IRB

If you read my previous blog post you might have noticed we already used it. But why do you need it? In a later blogpost we'll go into the details of writing scenario's and creating step definitions. In the beginning I ignored IRB a bit and just started the specific scenario that I was testing (I'll explain the details later, but just hear me out). Rerunning the test is fine, but if you need to tweak/tune a large test it becomes time consuming to run the test each time to see if it works or not. Also sometimes you just want to see a value of a certain element/object. Bit by bit I started to use IRB more and now I usually first try it out in IRB before I save it in my step definition. This way you'll be more certain that what you made most likely works. 

Browser developer tools

Most likely (at least I hope so) the developer tools are already known to you as a website tester. Because even for manual testing this tool is very useful. But just in case, here is some info about it in case you're new to it. I'll explain this using the Chrome browser developer tools, but the principle is the same for any browser and most items are even in the same place to some extend. So open Chrome, navigate to google.com and hit F12 on the keyboard. The browser developer tools are opened. Make sure the "Elements" tab is selected and make sure that what is below it is visible enough to read for you (you might need to drag and drop a bit, but you'll figure it out). Now right click on the Google searchbar and select "Inspect". You will notice that the HTML of that element is being shown in the developer tools. The attributes of this element is what we can use for our test automation scripts. If possible you take the ID (since ID's need to be unique according to the specifications), but if that is not available you can also use the name, class, text or any other attribute that you can use to identify the element. 

Lessons learned

• If the element has an ID attribute, use it, this should be unique on a website
• Try to avoid finding the element based on the text, first go for ID, class, or other attributes that make it unique (or a combination)
• Use IRB to figure out how many elements there are (e.g. find all and then count)
• If there are two of the same elements, think about how to select the proper element
• In lapis_lazuli using :context is very useful for this, but I'll get back to this topic later
• Not all developers stick with the guidelines for website design, so depending on the team you might need to improvise more or less
• Try not to blame the developers for mistakes (they should be your friends), convince them you need their help for the test automation to succeed (e.g. to let them add unique ID's if possible)