rafanoronha.speaking()

This post is part of a series about Database Integration Tests:

Part 1: Database Integration Tests – considering it
Part 2: Database Integration Tests – understanding it
Part 3: Database Integration Tests – implementing it

In this third and last part of the series, I’m going to demonstrate the implementation of Database Integration Tests.
Below is the representation of the table wich will embrace our testing scenario:

Then you have the source code of a simple java implementation upon the usage of junit and dbunit frameworks.

The relevant piece of code is inside the class CustomerIntegrationTest.
At the method setup(), we ask dbunit to clean the customers table and then insert some new customers as input data for the first test.

At the second test, we ask dbunit to look for the created customer in the database and compare it with the existing on in the xml file.

I’ll leave preferedCustomers.xml and newCustomer.xml as a homework for you, if you intend to hack with this implementation.

By the way, this is the end of the series.
Hope you enjoyed!

This post is part of a series about Database Integration Tests:

Part 1: Database Integration Tests – considering it
Part 2: Database Integration Tests – understanding it
Part 3: Database Integration Tests – implementing it

In this second part of the series, I’m going to briefly explain the main concepts coexisting in Database Integration Tests.

Feed the software with the data it needs

Before performing a given task, a software needs some kind of input data.
Once you make sure that the data is there, you are able to execute the software under test and check correctness of the output result.
Note that depending on your scenario, you may need to setup this data once a test fixture execution, or once each single test execution.

Query the database to check correctness of the output result

You set the database data and executed the software.
Now you need to check if the software did the job in the expected way.
If the output of your software is persisted to the database, you will need to query the resulting data and check if it conforms to the expectations over the performed task.

This is the end of the second part of the series.
In the next part, I’m going to cover the implementation of Database Integration Tests.

This post is part of a series about Database Integration Tests:

Part 1: Database Integration Tests – considering it
Part 2: Database Integration Tests – understanding it
Part 3: Database Integration Tests – implementing it

The purpose of the series is to present you the concepts and implementation aspects related to this technique.

In this first part of the series, I want to expose some ideas that you should consider before deciding to go with Database Integration Tests.

Integration Testing is about the behavior of more than one software component

It’s important to note the differences between unit and integration tests.
An unit test should cover expectations around an isolated piece of software – commonly a class, thinking in an object-oriented software.

An integration test, on the other hand, should cover expectations over the interactions between different software or infrastructure components.

Database can be saw as entry and exit points

Relational databases tend to play a key role for enterprise software.
There are two important aspects in their interaction with the software:
The database owns the needed data by the software for performing a given task.
The database receives from the software the resulting data of a performed given task.

Recognizing the importance of this interaction is what should lead you to the use of this kind of integration testing.

Different testing strategies solve different problems

It’s crucial to understand that there is no single testing strategy guiding you to the quality assurance of your software.

Each testing strategy will help you in different ways:
You should go with unit testing when you need to assure the correctness of many business rules and also the quality of your code.
You should go with integration testing when you need to assure that your software as a whole is playing it’s role in the expected way.

This is the end of the first part of the series.
In the next parts, I’m going to talk about the understanding and implementation of Database Integration Tests.

I have been mentoring an apprentice at Stefanini Software Delivery Center.

During the early follow-up, I thought that a code kata would be a good way to encourage the apprentice to solve programming problems.

To specify what I’d like to see implemented, I wrote a few unit tests, and explained how automated tests would help us.

I also introduced test-driven development, and how it might be useful during the code kata resolution.

A day after the apprentice was able to add more unit tests to the test suite, thus extending the program behavior.

What I realized is that TDD as a methodology of work, involves the apprentice in a cycle of continuous learning, disclosing how execution of each new instruction added to the program happens.

A great value brought by TDD as a tool supporting education is the fact that the student prematurely get used to specifying software behavior before implementation.

Another skill the apprentice would develop at a early stage is requirements analysis.

I’m very excited about where this is going to take us, and it has been also a great experience.

Sorry, this entry is only available in Portuguese.