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
Selenium tests tend to make a lot of use of assertions, to check that some actions have been performed on the front-end or that some WebElement properties are the expected ones. And by assertions, I mean, mostly: assertEquals or assertTrue, as these are the most commonly used ones.
Assertions fail too often due to the condition they are checking not being fulfilled by the time the assertion code executes. Had the assertion run a few seconds later, in many cases, it would have passed. It’s all about timing. In my previous posts I described some of the WebDriverWait based methods you can find in my ‘thewaiter’ library. In this post I want to highlight how you can use these methods to replace your assertions. Continue reading Use waits as assertions for your Selenium tests
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
Do you know this situation, when you implemented some automated tests based on a requirement, but a test has been failing for ages because a bug in the implementation was never fixed? Continue reading A bug is still a bug