Skip to content

Don't Panic! Posts

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.

Deploying to Tomcat 7 with Maven

The Tomcat7 plugin for Maven has a number of uses. In a previous post, I’ve looked at using it to deploy a build to an embedded Tomcat server for integration testing with Selenium.

A more simple use case is to simply deploy (or undeploy) a built artifact (war) to a Tomcat installation on a local machine or on a remote server.

The following examples are available to download from the Spanners Demo on GitHub.

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.

Migrating from SVN to Git

The Spanners demo project is now available on GitHub: https://github.com/hotblac/spanners. Feel free to fork!

I wanted to migrate the Spanners demo from SVN to Git, partly so I could take advantage of GitHub to host it (yes, I know I could host a SVN project on GitHub but where’s the fun in that?). I also wanted to start using a Distributed Source Control Management (DSCM) system and Git is certainly the most popular of these. Even though I’m (currently) the sole contributor to the Spanners demo project, it’s useful to understand how a DSCM system differs from a ‘traditional’ centralized server based SCM such as SVN and CVS.

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.