What do I mean by “automated regression testing”? I am not one for debating for hours what this means, so let me give you my interpretation (not definition), so that we are on the same page: whenever you are performing a new release, you need to make sure the features you released some time ago still work properly. For that, you will need to run some kind of tests, to ensure the features are still working as expected. You could do that manually, but running the same manual test cases repeatedly, for each release, takes a lot of time and quite frankly, becomes boring or even frustrating at one point. Hence, the suite of automated tests comes in handy. Having these in place will allow to verify plenty of scenarios while you can do something more enjoyable during the test run. Continue reading The Automated Regression Suite. Part 1 of 3. When to create the tests for regression
Context: you need to check that the values you have in a List of Strings are the same as the contents of a file. An element in the List will correspond to an entire line from the file. How can you achieve this easily? Continue reading Easily compare a list of Strings with the contents of a file
If you are an automation tester, you will need to write a lot of code to cover the required test scenarios and test cases. Your code base will grow and grow, but some of the code will not be really needed and thorough code reviews should be done, to avoid unnecessary code.
Such unneeded code might include forgotten and unused imports, duplicate code that should have been extracted in a separate method or variables that are declared only to be used in one place. Continue reading Better Test Code Principles: #6 Don’t create a new variable for a value you will only use once
Starting an automation effort for a project that has no automation whatsoever is always a fun and challenging experience. But you need to clearly understand what the goal and specifics of your project are, to achieve success in the automation effort. Before jumping into writing the first automated tests, you need to gather some information, perform some analysis, and build a Proof of Concept, to make sure you picked automation tools that really work on your product. Continue reading Create a Proof of Concept before going full throttle with your automation
Writing automated tests means writing code. It means going through processes that regular code goes through. Like code review, and refactoring. I see a lot of hesitation when it comes to refactoring one’s own code, possibly because we feel that if our code needs correction, we did a crappy job writing it the first time. But that is not the case, and refactoring should be seen as a good thing. It is meant for changing something from good to even better. Continue reading Refactoring is allowed
Element text is something you will often check for when writing Selenium tests. Whether it equals a given String, or contains a given String. But you can extend your checks to whether: the element text equals/contains a String ignoring the case of the two, or whether the element text equals/contains a String ignoring any whitespace the two might contain. Continue reading thewaiter: wait for WebElement text. To equal, contain a String with variations.
In some tests it is not enough to just wait for a page to fully load, but instead you need to make sure that the URL corresponding to that page is the expected one. Maybe you clicked on a button and need to make sure an expected page/URL opened, or maybe you are opening a page but a redirect changes the URL to something else than the initial page had. For such tests you can use the URL related wait methods from ‘thewaiter’ library, to wait until the URL is the correct one, before performing the rest of the test. Continue reading thewaiter: waiting for a URL in the browser to equal or contain a String, with Selenium