Most of the times your automation code project travels around, from machine to machine, to where the tests inside it need to run. Sometimes it might be your colleague’s machine, who also wants to run/update/add tests, but other times it will be some CI/CD entities, like physical or virtual machines, containers, and so on.
Continue reading Artifacts to store in your test automation project
Automated tests are supposed to help validate that the product under test is working as expected. For that, a key ingredient is required in your automation: the actual testing. Just as, when you are performing a test case yourself, you are visually inspecting that the expected behavior occurred, so does your automation need to have verification in place. And that verification needs to be implemented by you. Here are some thoughts on this.
Continue reading Adding testing to your test automation
If in your tests you need to generate date values representing, let’s say, today’s date, or yesterday’s, or one year from today, or the last day of the current month, this post will help you do just that. Using Java’s LocalDate, you will be able to generate the date (meaning year, month, day) your tests require easily. Continue reading Generating useful date values for testing purposes
Read the article i wrote for the TestProject blog on general tips for why and how we can achieve clean code in our automation: https://blog.testproject.io/2020/04/22/clean-code-in-tests-what-why-and-how/
Branches are beautiful, on trees. Branches in the code are not what many testers like to work with. The whole branching process appears to be very cumbersome: creating the branch, keeping it up to date with the main branch, deleting it once the work is done, these all seem to take a lot of time and to not be the most fun activities. However, there are some situations when branching really needs to be considered. Continue reading Why using branches is good for your tests
Some of our test data needs to be transformed from its original type to something else. For example, we might need to convert a String to a numeric value, or vice versa. Or we might need to generate date values in a certain format. Examples for all of these can be found below.
Continue reading Useful type conversions
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
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
imalittletester 