Naming is one of those underrated things when it comes to test automation code. Many times, when you look at variable or even test method names, they are not very suggestive and you have a hard time figuring out what their purpose is. In this post you will find a few reasons why it is important to name things properly, and some tips about how to find the good names your code deserves. Continue reading Better Test Code Principles: Use proper naming, for everything
Once you have your automated regression suite in place, you can create a scheduler to run them periodically, without any manual intervention. Mostly you will use Jenkins jobs (or some similar CI tool) to trigger them and have them running on an environment of your choice. Just because they are called “regression tests” it does not mean they are only meant to be run once before a release. They are in place to help validate your system, so you can run them as often as you want. Continue reading The Automated Regression Suite. Part 2 of 3. When to run the tests.
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