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.
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.
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→
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→
