It all started over 6 months ago. I heard about Nordic Testing Days being an awesome conference and i really wanted to be a part of it, as a speaker. Having never been to Estonia, the location was also a nice plus. So i submitted some talk ideas and the guys from the organizing team were kind enough to accept me as a workshop deliverer…workshoppee…well a speaker who does workshops. Continue reading My Nordic Testing Days 2017 conference experience
Using try/catches to handle exceptions has become quite fashionable when writing tests with Java. However, this approach is also a frequent source of having false positives while running tests. Many times when writing the tests people forget to consider both sections of this code block: they forget to write the appropriate code in both sections – the code that deals with not encountering the exception (if the code in try executes) and the code that deals with encountering the exception (if the code in catch executes).
Yey, the program for the 2017 edition of the Nordic Testing Days conference has been published, and i am glad to be among the people speaking. More specifically, i will be running a two-hour hands-on, coding workshop on Selenium tests, the Object Oriented way. It will be a very practical workshop, where one can learn how to think in an OO fashion when it comes to testing complex modules or modules that appear in several areas of the page to be tested.
Check out the full program of the conference here: http://nordictestingdays.eu/schedule and don’t forget to get your tickets! It will be great.
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
In my previous post i talked about how to check whether an element is displayed or not. There are times when tests where such an action is performed fail randomly (sometimes they will pass, other times they won’t). The assumption here is that the element was not displayed within a decent amount of time when there were test failures, but would have appeared later on. Therefore if the test would have waited a little bit before performing the presence check, it would have passed. Continue reading Selenium: How to wait for an element to be displayed / not displayed
When you have more than one assertion in your test, you might want one of two things:
- Have your tests fail once the first assertion failure is encountered.
- Have all your assertions run, no matter if they have passed or failed. Of course, after they are run, if there are failures, you want the test to fail, and also show you where the issues were.
Suppose you are starting work on a new piece of software that you will need to write automated tests for. Your goal is to cover the most relevant test scenarios that apply to the feature , without missing or forgetting one. Below are a few steps (guidelines) to help you achieve identifying those required scenarios (a sort of ‘how i do it and it works for me’ guide). Continue reading How to identify the test scenarios you have to automate