A Test Automation Blog

A picture sometimes says more than words. This is also true for test automation. Therefore it could be that you want your framework to make a screenshot when a scenario is failing to make debugging more easy. But how can you make sure your framework does this for you? Since we're using the `lapis_lazuli` gem, this is actually already been taken care off for most scenario's, but if you're using the 'watir' gem, you need to modify your `hooks.rb` file like briefly described on this page . Let's first look at Watir and then move to LapisLazuli to see what advantages and disadvantages are between the two. Watir screenshots Watir by default does not make a screenshot of a failing test, so you need to write some code to make this work. Below a Watir example Keep in mind that this only makes a screenshot at the end of the scenario. Meaning that it can happen that the screenshot is being taken a fraction later and thus missing the real issue. So let's t...

On most websites and applications you might need to fill in a form of some kind. Some people like to `click` in each field with the mouse, others like to use the `tab` button on the keyboard. But do you need to script both of these scenario's for your automated tests? https://www.service-hub.com/ contact form What to test and why? There are a bunch of additional questions that pop-up in my mind when I ask myself the question: "`Click` or `Tab`, which will be required in our test automation suite?". Because sure, we can automate both scenario's, but why is this needed? Would it be sufficient to automate only one of these? Can we mix them (most fields click and only one tab)? Will automating it save us time/effort?  The answer is simple: "It depends on what you want to test and what the test should be covering".  If you want users to navigate through the website with keyboard tabs, you should test this. If you want users to navigate through...

When building a solution for mobile users there are a bunch of solutions to choose from. Responsive Website, Progressive Web App, Android/iOS WebApp or Android/iOS App. All come with advantages and disadvantages. If you have a website that is responsive it's very easy to turn this into a (webview) WebApp. But do you need to test this? And if so, how do you test this? Android WebApp Let's look at a simple Android WebApp example. We now just turned a simple website into a Android WebApp. You will notice you can navigate through the website and when you use the phone back button, it will first navigate back on the website itself unless your at the initial loaded page, in which case it will close the WebApp. It looks just like the regular website, but can we test it the same way? And/Or can we test the responsive website and assume the webapp works just as fine as the webview app? To test or not to test? If you have a simple website, only testing the responsive website ...

In case you've never head of the phrase "All Roads Lead to Rome", it refers to the fact that many routes can lead to a given result. The same counts for finding elements on your website under test. There are many attributes which can be used to find the element you need. So let's have a look at a bunch of functions/options with the `lapis_lazuli` gem to limit the amount of roads a bit but still keep the test reliable. Side note Let's start with something I mentioned in a previous post , but it's good to keep in mind. The ` lapis_lazuli ` gem is an extension build on top of the ` watir ` gem. Even though I focus on LapisLazuli functions, you can also use the Watir way instead to locate the elements or even combine the two to a certain extend. Documentation All LapisLazuli documentation for locating elements can be found on the testautomation.info website. And also on github , but this is less complete. Since most of the element selection information...

When you just start with test automation, you most likely search and interact with elements within your `*_steps.rb` files (the files that contain the precondition, interaction and validation steps). So most likely across the steps, you have repeatedly located and interacted with the same elements a couple of times. And as long as your test suite is small, adjusting it only takes a small bit of time and it works, so who cares, right?  But now imagine you have a 100 scenario's, 100+ (precondition, interaction and validation) steps. And in a bunch of them you've locate the same element. But because of a change in the website this button cannot be found anymore. Are you going to adjust this in every line in your code to fix? Your answer should be: "NO!". You could use nested steps , but this becomes really confusing really fast and is not a good practice. So let's have a look at a proper solution, the helper files. Structure We basically define four main layers i...

You now have this beautifull generated test automation suite and you want to adjust it to your needs, but have no clue where to start. Don't worry, because that is exactly what we're going to cover in the next couple of posts. In this post we'll add a new scenario, make some small adjustments to a step, add a new step and run only that one test to check the results. Cucumber Let's start with a test run with Cucumber. Navigate to the folder in which the tests are stored. So in this case in ` C:\TA\testproject `. In this folder type ` cucumber ` and hit the enter key to run all tests from your generated test suite. But you can also run a limited set of tests. To do so, you should make use of tags in your scenario's . To run only one test you can run it like this ` cucumber -t @whatever `. It will now only run tests that are matching this specific tag and ignore all others.  Add a scenario and run it Let's start with adding a new scenario. For example ...