This is something i heard quite a few times: why bother writing automated tests, as they will not find any bugs anyway? Continue reading A false myth: automated tests don’t uncover bugs
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
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
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
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.
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)
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