Integration Tests with Selenium and tomcat7-maven-plugin

Published on January 18, 2013

Integration tests are a valuable tool in the development of robust, quality software. Once each individual component has been unit tested, the integration test gives some confidence that the system stack as a whole does what is expected. Like unit tests, a great deal of the value of integration tests comes from the regression suite that they create. After any defect fix or enhancement to software, the unit and integration tests confirm that all existing features do exactly what they did before. If these tests are automated, they cost nothing to run and they’ll stay silent unless a defect is discovered.

I’ve looked at unit testing a few times in the past but this post explains how to integration test the full stack – database, Java application and web server. In this case, I’m running the tests as part of the Maven build lifecycle. As usual, I’m working from the Spanners demo (available for download), mainly working against the spanners-struts web component.

Protecting Service Methods with Spring Security Annotations

Published on August 19, 2012

Spring Security is typically used to protect Web Applications by restricting access to URLs based on a user role. However, it can also be used to secure methods and classes so that coding or configuration errors do not allow a back door into restricted data. This builds security deep into the system without cluttering the code. It also allows additional flexibility such as allowing users to access only information relevant to them and not to other users’ information.

DbUnit and Jailer

Published on November 23, 2011

The easiest way of creating datasets for DbUnit tests is often to script out values from a real database. This can be done with a few lines of code in DbUnit itself (see DbUnit FAQs) but it’s easier to use a database tool that can export to DbUnit dataset files. Jailer is one such tool. In its own words:

Jailer is a tool for database subsetting, schema and data browsing. It exports consistent, referentially intact row-sets from relational databases. It removes obsolete data without violating integrity. It is DBMS agnostic (by using JDBC), platform independent, and generates DbUnit datasets, hierarchically structured XML, and topologically sorted SQL-DML.

It’s pretty easy to set up and has the advantage that it can flexibly script target data as well as all associated data necessary to satisfy foreign key constraints.

Continue readingDbUnit and Jailer

Just tell me what broke!

Published on November 6, 2011

A few years ago, I heard about Glassbox, an automated troubleshooting tool for Java apps. The Google TechTalk seemed interesting (if a little long) and I was reasonably impressed when I plugged it into my own apps and it made (mostly) helpful suggestions on what may be causing bottlenecks. The tagline Just tells you what broke™ summed up the product perfectly. It didn’t go into unnecessary detail regarding CPU cycles, memory usage, garbage collections, locks, threads and so on. It just showed nice helpful messages like “Slow operation. Cause: Slow database operation”.

Unfortunately, this open source project has ground to a halt and there have been no new releases since 2008. And unfortunately it never quite managed to become completely usable. I’ve tried installing it again recently on a couple of different setups (WebSphere / IBM JDK 1.5 and Tomcat 6 / Oracle JDK 1.6) but never got it doing anything actually useful.

I now have a new project that I suspect is running poorly. There’s probably some problem with the database or nested loops or something like that. I don’t know exactly where the problem is though. I’d like to be able to use a tool like Glassbox to point me in the right direction. I don’t need it to solve my problem for me. I just need to know what to do next. Do I run a heap analysis or do I check my database indexing? So I’ve been looking for replacements for Glassbox.

Web service testing with soapUI

Published on March 19, 2011

In my previous post regarding Spring-WS and Security I didn’t mention anything about testing the resulting SOAP service. Particularly when it comes to secure services, it’s vitally important to test. First, we want to make sure that the service is functionally correct – that it returns the correct results. Second, we want to make sure it is secure – that it refuses service to any request that does not meet our security requirements.

With regard to how we test, it’s simplest to use some SOAP editor tool that lets us fiddle with the request and press a button to retest instantly. But ideally we want some programmatic test that can be included in the test phase of our build.

This post describes testing the now legendary Spanners WS demo with the following requirements:

Tests must be functional – they test what the webservice does
Security is tested
Tests can be tweaked and rerun instantly
Tests can be included in build process

The updated source of the Spanners WS demo including the tests described here is available to download.

Continue readingWeb service testing with soapUI

Rounded corners in CSS / IE Tester

Published on March 1, 2011

Until Internet Explorer 8 is finally retired we still have to dick about with CSS to make IE behave properly. I’m not a CSS hacker but this is one trick that I suspect I’ll need again at least until IE9 becomes standard.

CSS3 includes a property for rounded corners which was (sort of) adopted in Firefox, Chrome and Safari some time ago. I don’t use it on this site – someone else did the hard work there using images for the corners. Presumably because CSS3 support was so poor at the time. This new CSS3 property can however be retrofitted to old browsers with a little work.

Test Coverage

Published on December 12, 2010

I’ve been looking a lot recently at JUnit (and TestNG) tests on a code base I’m not too familiar with. In many cases I was not convinced that the tests were adequate but it took a fair bit of investigation before I could be satisfied that this was the case. I would need to look at the tests, then look at the code it’s meant to exercise, then try to work out in my head if the test covers everything it should. To make this process a bit easier, I’ve started running code coverage analysis using Emma. While this doesn’t tell me if the test is good or not, it does show me at a glance how much code is covered by the test and exactly which lines, methods and classes are missed. This is usually a good first approximation for the quality of the test case.

I’ve found Emma to be a useful tool to run after I think I’ve written my test cases and got them working. Running the test case tells me if the code being tested works. Running Emma tells me if I’ve tested enough of the code. There’s no point in having 100% test case successes if the tests themselves only exercise 50% of the code.

DbUnit

Published on December 1, 2010

I’ve decided to revisit the JUnit testing Hibernate and Spring recipe that I posted a while back. A problem with the previous recipe is that it did not provide any means to initialize the test database. This wasn’t too much of a problem as I was mostly testing the data insert operations of the DAOs. I then used the same DAO to retrieve the newly inserted data and tested what came back. However this is no good if I don’t want insert operations on my DAO (if it’s to retrieve read only data from the database) or if I want to test the retrieval operations independently of the insert operations.

This post extends the recipe to include a means of initialising the database using DbUnit.

Bug Shooting screen capture

Published on November 10, 2010

Bug Shooting from http://www.bugshooting.com/

Memory usage

Published on April 10, 2010

A year or two back I was working on a web application which was expected to have moderate use – around 50 concurrent users. The product was generally getting thumbs up from our QA guys. It did everything we expected it to do. Then we had a go at testing under load.

Bang!

We found that if we had only a few users hammering the system for any length of time, the memory usage became unacceptable. Simple maths showed that the problem was to do with the number of open sessions. Each session required 20-30MB of memory from the app server. This is a piddly small amount when we have a handful of test users. It went completely unnoticed against the background noise of a typical server’s memory use. However, once just a hundred sessions have been opened (not necessarily at the same time) we’re chewing gigabytes at a time.

Tag: testing