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
Tag Archives: test
The Automated Regression Suite. Part 3 of 3. How to run the suite
Once you have a regression suite set up, you will need to run it. When you have a smaller number of tests that need to be run on a specified day, that won’t be a problem, and the tests will successfully finish running within the allocated time period. However, as the suite becomes larger and larger, so does the amount of time required to run all the tests. In some cases, you can even get beyond a 24-hour test run. So, what can you do to optimize the test run time? You can use two strategies: parallelize and split. Continue reading The Automated Regression Suite. Part 3 of 3. How to run the suite
Share this:
The Automated Regression Suite. Part 2 of 3. When to run the tests.
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.
Share this:
The Automated Regression Suite. Part 1 of 3. When to create the tests for regression
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
Share this:
Refactoring is allowed
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
Share this:
A bug is still a bug
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
Share this:
The tester and the code review
Code review, although very important and frequent in the software development world, is not as frequent in the automation testing world. Normally, it would be part of the whole process: someone writes code, reviews it, makes it available to the rest of the team, they review it, and if changes are needed they will be made, and the improved code will now be available back to the team. This helps in having better code and having awareness inside the team on what is being implemented.
Code is still code, no matter whether it is created for implementing or testing a feature, so there should be code reviews for all of it. Continue reading The tester and the code review
