Brown Bag Series: Writing Tests

For the first part of the Software Testing series, read here

In this brown bag session, Muizzuddeen Ma’aji, one of  FlexiSAF’s Software Engineer, develops the idea of writing tests. The short talk explained testing and it types, why we need these tests and further examined one of them with sample code from one of our projects SRMS as a case study.

Software testing is one of the parts of the software Development Life Cycle (SDLC). The software is not complete without undergoing testing.

What are Tests?

Tests are pieces of code written by a programmer to verify that a relatively small piece of code is doing what it is intended to do. They should be easy to write and execute, and their effectiveness depends on what the programmer considers to be useful.

Types of Tests

There are various types of tests, but in order not to widen the scope of this session I would only mention two:

  1. Unit Tests.
  2. Integrations Tests (itest).

Unit Tests

These are conducted by developers and they test the unit of code he or she developed. It is a testing method whereby individual units of source code are tested to determine their readiness for use. It helps to reduce the cost of bug fixes.

Integration Tests (itest)

These are executed to test integration between modules. It is a software testing technique where individual units of a program are combined and tested as a group.

In this article, I am going to explain more on itest  using the SRMS project as a case study. The type of itest executed on SRMS usually focuses on database operations. The database is one environment, while the application data layer is another. The objective of our itest is to ensure that these database operations provide the expected results. On SRMS, we use Java Persistence API (Java EE’s ORM framework) for the management of the relational database.

In JPA, an annotated class, called the entity, is mapped to a relational database as  shown below:

Once you have the entity in place, you can create a  corresponding entitymanager in  JPA to enable it perform all required transactions on that entity. These transactions are usually known as the CRUD Operations, which stands for Create, Read/Get, Update, and Delete.

Below is a sample entity manager:


The entitymanager class is what you would use to create your test class, as shown below:


To make our test most efficient we use Arquillian. You write a basic test case and annotate it with declarative behavior that says, “@RunWith Arquillian”  as shown in the figure above. This declaration tells Arquillian to take over execution of the test when it’s launched. That’s when the real magic happens.

To avoid a myriad of problems that could occur whenever we try to read/ get, update or count existing entries in the database, we use

 DbUnit’s getLookUpName(), getDataSet() and JUnits’s @BeforeClass on startUp(,)  

gotten from the extended class JndiBasedDBTestCase using an xml file to ensure a particular set of data is always available for the test to use as indicated above.

Below is the sample xml file:

Once you have all these done, launching Arquillian test is as simple as right-clicking the test class in the IDE and selecting the ‘Test Class’ option. Alternatively if you’re using gradle as your build tool, you could run this command:

(gradle -Dtest.single=MaritalStatusEntityMngrTest test) 

from the terminal after navigating to the projects’ directory.

If everything goes well you’ll get this colorful success message saying all tests have passed