Skip to content

Category: Testing

Building Unit Test Data

Unit tests have most value when they’re easy to read and understand. Unit tests typically follow a very straightforward pattern:

  1. Simulate system state
  2. Call the method under test
  3. Verify the method’s result and side effects

So long as this pattern is obvious in the test, the test is readable.

Testing for SimpleDateFormat thread safety

It’s a little alarming how many good developers are unaware that many standard Java classes – including subclasses of Format – are not thread safe. Many are also not sure about how their applications perform in a multi-threaded environment or how their web application container (Tomcat) will run their app in multiple threads. This can cause nasty intermittent bugs that can be incredibly hard to find and fix. It’s important to be aware of threading issues at development time but it’s also important to be able to test for them.

Coding in the Age of Distraction

I must have seen a hundred blog posts suggesting that the best way to become more productive is to minimise distractions: Switch off IM, disconnect the phone, block out quiet time, get a private office and so on. While I’m sure that these would be of benefit, sometimes distraction is inevitable. I could switch off IM, email and my phone but I happen to work at the desk next to my boss. Convenient as it may be, my boss does not come with an off switch. Also, priorities happen. I may believe that my ‘in the zone’ coding time is golden and must not be interrupted on pain of code diva tantrum. However, if the production server goes down then scheduling a fix next week is just not good enough. Finally, I do on occasion like to stop work for the day and go home. A good night’s sleep is definitely a distraction from work but also I think quite important.

It’s certainly worthwhile arranging your environment and schedule so as to minimise distractions. But it is also important to accept that distraction will happen and to plan for it.

Integration Tests with Selenium and tomcat7-maven-plugin

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

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

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.

Just tell me what broke!

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.