Most of the testing tasks require some data processing, whether it is working with JSON objects, gathering data from a database, processing Strings, working with date types, and so on. Performing the processing requires some code to be written, apart from the tests themselves. But why write that code yourself, if it already exists in an easily usable external library? Continue reading Better Test Code Principles: #3 Use external libraries when available
Category Archives: automation
@FindBy, Lists and using them to check for similar UI elements
This is going to be a rather complex post, that will show how to easily check for values of similar UI elements. By similar i mean elements that share some kind of properties: whether they have the same CSS selector, or are part of the same group of elements. Some examples will be shown below. Performing the testing part will imply the use of @FindBy (of Selenium WebDriver) and List (of Java). Read on to get an idea of where this approach can be used, how @FindBy is ideal for such a task, what the basics of working with List are, and what an actual test looks like. Continue reading @FindBy, Lists and using them to check for similar UI elements
Share this:
Better Test Code Principles: #2 Don’t generate ALL your test data in @BeforeClass
A considerable amount of tests will need some test data to be generated previous to them running. Some people prefer to put all the data creation for all the tests in a class into the @BeforeClass method, some others prefer to keep the prerequisite data creation inside the tests themselves. Continue reading Better Test Code Principles: #2 Don’t generate ALL your test data in @BeforeClass
Share this:
Better Test Code Principles: #1 Don’t copy/paste the code. Reuse it.
When starting to learn Java, one of the first things you are taught is that a class consists of several things, among which are the ‘methods’. A method is nothing more than grouping of several code lines. Since tests are code, the same principle applies to writing your Java based tests. Especially if you are dealing with duplicate code (code you keep copy/pasting all across your test project).
So what would be the reasons for not wanting to duplicate your code, but instead grouping it into methods: Continue reading Better Test Code Principles: #1 Don’t copy/paste the code. Reuse it.
Share this:
Selenium tests, the Object Oriented way – example 1 (with code)
This is going to be a follow-up post in regards to the approach i showed at my SeleniumConf talk, on doing Selenium tests by using an Object Oriented approach.
I will have a series of such posts, to show more examples and to make it easier to understand how to use it. All the code presented here will be available in GitHub under this location: https://github.com/iamalittletester/learning-project. Continue reading Selenium tests, the Object Oriented way – example 1 (with code)
Share this:
GitHub project available with code examples
Here’s a new and (possibly) cool feature regarding the blog: there are now code examples to be checked out and tried that you can download from Github.
The code location is: https://github.com/iamalittletester/learning-project.
Here are some details and how to run the test project: Continue reading GitHub project available with code examples
Share this:
Write clean code for your tests by using the separation of concerns principle
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
Share this:
Selenium: How to wait for an element to be displayed / not displayed
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
Share this:
Selenium: How to correctly test whether an element is displayed (or not)
One of the most frequent kind of interactions with the web page when testing with Selenium is checking whether a particular element is present. More specifically, whether it is visible when looking at the page and does not have a “hidden” attribute. The isDisplayed() method is used for such checks, but in many cases it is not used properly. Some tests appear to be unreliable Continue reading Selenium: How to correctly test whether an element is displayed (or not)
Share this:
SoftAssert – don’t make your test fail on the first assertion failure
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.
Continue reading SoftAssert – don’t make your test fail on the first assertion failure
imalittletester 