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
It occurred to me lately, after chatting with some people from the testing community, that not everyone runs automated tests or does any kind of testing in the production environment. For me that seems a bit unnatural, since i have been doing it on all the projects that i worked on. So, here are a few thoughts that might convince you that you do need to run automated tests even in production: Continue reading Why you need to test your production environment
You are writing some automated tests with Selenium, that require you to fill in some text fields in a form. You are pretty confident you typed the values you expected to type, into the field you expected to type into. But, here are just 3 reasons why you should write some code that checks that you actually wrote what you thought, where you thought, before submitting the form you are trying to fill in.
Continue reading Check that the value you think you typed into a field has actually been typed correctly
When automated test are running, they are either running on your own machine (when you write them or run them to check something), or in your CI.
When you run the test on your machine, if there are failures, it might be easy for you to look at what is running (if you have some visual tests, that interact with either browsers or apps on your machine). You can just rerun a failed test and visually inspect for failure reasons. But, if tests are running on a CI machine, visual inspection is either very difficult or even impossible. You might not have access to connect to that machine, or to see how tests are being run. Continue reading Test design: write tests with proper console output to easily identify failure reasons
Automated tests are used to validate features in development environments but also in production. Whereas the classic approach of keeping all tests in the same code project is the most popular, it is not the best idea (and by code project i mean for example a Maven project). Continue reading Better Test Code Principles: #4 Keep your production tests separate from your dev environment ones
When i look at a test class, what i want to see is clean code. What i mean by that is, well a few things, but the most important one: i want the test class to hold the code for the tests, not the code for everything but the kitchen sink.
When we write tests we have a lot of data to prepare for them. Whether this is the ‘expected’ or the ‘actual’ data used in the tests, or some auxiliary code that we need, there always is some processing that needs to be done, apart from the actual asserts that a test should do. What the test class should contain is only the checking / asserting part, while having specialized classes generate all the data that is required in the test. A test class should only check the actual data against the expected data. This is the separation of concerns principle. Continue reading Write clean code for your tests by using the separation of concerns principle
So this year’s edition of RTC (Romania Testing Conference), held in Cluj-Napoca, has just concluded, and as a participant and speaker i had a great time attending the event. Therefore, here are some impressions and takeaways from a full day of presentations and meeting some really lovely folks. Continue reading Impressions after the Romania Testing Conference 2016