• No results found

Chapter 6 Performance Test

6.2 Implementation of Test Design

For the purpose of this research, a Java based testing application was developed and integrated within the Grasshopper project. Therefore, the testing environment builds on the same DAO design pattern as the Grasshopper application itself. The abstraction layer introduced by

DAO supports easily switching between the tested ORM technologies by changing testing application configuration parameters. With a little programming effort, the developed design allows switching to and testing any ORM framework, supported by Spring DAO.

The structure of the testing system is depicted in the Figure 6.2.1. The testing facility is comprised of the main testing Java files; resources needed for setting configuration of testing environment and property files that allow changing test parameters (see Appendix H for the full source code).

Figure 6.2.1 the structure of the test system

The testing system for the CRUD operations builds on the following strategy. The SingleUserLoad.java interface defines abstract methods needed for performing the tests. The

name of the interface indicates that the tests are performed under a single user load. The

following code snippet shows an example of the methods, such as a method for deleting tickets, a method for counting sold tickets, and a method for counting seats on the stadium:

/* Load tests (business logic methods) */

Set<Ticket> insertTickets(Matches match, Set<Seat> seats);

void reserveTickets(Set<Ticket> tickets, User user, int bookingAmount); void deleteAllTickets();

void deleteTickets(Set<Ticket> tickets); Integer getSoldTicketsCount(Matches match); Integer getOverallSeatsCount();

Before running the tests, the test database has to be populated with the test data. For this purpose, a set of assisting methods has been defined, including a method for cleaning the database from data, a method for creating users, tickets, sections, seats and matches, as the following code demonstrates:

/* Initialization methods */

void cleanDB();

User createTestUser();

Set<Ticket> createTickets(Matches match, Set<Seat> seats); Set<Section> createSections(int amount);

Set<Seat> createSeats(int amountOfRaws, int amountOfSeatsInRow, Set<Section> sections);

Matches createMatch();

The SingleUserLoadImpl.java class implements SingleUserLoad interface. It implements abstract methods, defined in the SingleUserLoad interface, injecting them with the corresponding DAO methods, created and discussed earlier. Both, standard DAO methods, supported by the GenericDao, and user-defined DAO methods are utilised. For example, the

getSoldTicketsCount() method is implemented with the corresponding user-defined method in the MatchesDao.java interface as follows:

public Integer getSoldTicketsCount(Matches match) {

return matchesDao.getSoldTicketsCount(match);

}

The assisting cleanDB() method for cleaning the database utilizes generic deleteAll() method to delete all data from the tables:

public void cleanDB() { userDao.deleteAll(); bookingDao.deleteAll(); ticketDao.deleteAll(); matchesDao.deleteAll(); seatDao.deleteAll(); sectionDao.deleteAll(); }

Once the database operations methods have been defined, they are used to implement the test. The high view of the testing program workflow is depicted in the Figure 6.2.2.

Figure 6.2.2 The test program workflow diagram

The initialization methods populate the test program with data needed to perform the test. The total execution time of database initialization is captured with the StopWatch utility, an API for timing from the Apache Sotware Foundation. The methods start(), stop(), get() and reset()

provide facilities to start the StopWatch, to stop the StopWatch, to get the time on the

StopWatch, and to reset the StopWatch respectively. The results of this activity, such as the total execution time of database initialization are logged into a log file, for further analysis. The logging functionality is implemented by the means of the LogFactory, another utility by Apache Software Foundation. Once the database is ready for running the test, the methods providing for the test logic have being invoked. The execution performance of the each persistence operation has been captured and the results are logged. Additionally, the total work time, taken for

performing the whole test set, is been measured. In the end, the cleanDB() method deletes all the data from the database. The time needed for the cleaning operation is logged into a log file.

The SingleUserLoadImpl.java class implements the testing functionalities by the means of DAO persistence methods, without a hint on a particular ORM technology. The test runner for a given ORM technology is utilized through the configuration settings of the Spring application context. The following code snippet from the SingleUserLoadHibernateTestRunner.java class shows how the test running program is configured for testing Hibernate:

public class SingleUserLoadHibernateTestRunner {

public static void main(String[] args)throws Exception {

ApplicationContext context = new ClassPathXmlApplicationContext( new String[] { "test-applicationContext-hibernate-propertyConfigurer.xml", "applicationContext-datasource-dbcp.xml", "load-applicationContext-datasource- propertyConfigurer.xml", "applicationContext-hibernate.xml", "load-applicationContext-main.xml" });

SingleUserLoad singleUserLoad = (SingleUserLoad) context .getBean("singleUserLoad"); SingleUserLoadImpl.setLoggerClass(SingleUserLoadHibernateTestRunner.cla ss); singleUserLoad.executeTests(); } }

The next chunk of code, taken from the SingleUserLoadJpaTestRunner.java class demonstrates that as little alterations as changing application context configuration parameters, are needed to implement the test program for EclipseLink:

public class SingleUserLoadJpaTestRunner {

public static void main(String[] args)throws Exception {

ApplicationContext context = new ClassPathXmlApplicationContext( new String[] { "load-applicationContext-datasource- propertyConfigurer.xml", "applicationContext-datasource-dbcp.xml", "applicationContext-jpa.xml", "load-applicationContext-main.xml" });

SingleUserLoad singleUserLoad = (SingleUserLoad) context .getBean("singleUserLoad");

SingleUserLoadImpl.setLoggerClass(SingleUserLoadJpaTestRunner.class); singleUserLoad.executeTests();

} }

The two examples stated above provide an evidence of advantages introduced by the abstraction layer in the application, utilizing the Spring DAO design pattern. Any ORM framework, supported by Spring DAO, can be implemented and tested without changing the logic of the test program.

The programs, testing table joins, were built on the same principles as the single user CRUD operation test described above. The full source code of the joins testing programs is stated in the Appendix H.

SingleUserLoadHibenateTestRunner.java, SingleUserLoadJpaTestRunner.java,

JoinsLoadJpaTestRunner.java, and JoinsLoadJpaTestRunner.java classes, running the tests, can be executed either directly in the Java virtual machine environment, or functionalities

programmed into the buil.xml file (see Appendix G for the source code) can be used to build the build_load_test Ant task for executing the whole test set.

Related documents