The MockMVC class allows tests to be run against a real Spring application context without actually having to run the complete application in a Servlet container
Stuart 'Stevie' Leitch on Software Development, Java Technologies, Security and Testing
The MockMVC class allows tests to be run against a real Spring application context without actually having to run the complete application in a Servlet container
In less than five minutes and just three Maven commands, I was able to create, compile and run a fully working example Spring MVC application.
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.
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.
Hibernate can be used to map Java classes to existing database tables. More often, the Java classes come first and the database is created around the mapping. If that’s the case, you’ll want to define your database schema directly from Hibernate mappings rather than hand crafting DDL scripts. Hibernate offers a couple of ways to do this.
Properly versioning and releasing code can be fiddly if it’s done properly. If you’re not cutting corners, the process involves several steps. If these steps are performed manually the process is error prone and time consuming. I’ve often found it’s easier just to cut a few corners. Why change the version in the Maven pom when you could perform all releases against a single SNAPSHOT version? Why tag the release build when you could probably work out the release version from a Subversion log? Why put release artifacts in a release repo when you can rebuild from a historic version?
I’m not going to argue that you shouldn’t cut corners when creating a release build (all the same, just don’t!). I will argue that the process need not be fiddly. So long as a Maven project is correctly set up, the whole thing can be done with a single command. Wire that single command up to Hudson, Jenkins, CruiseControl or whatever and you can create properly versioned release builds in a single click or (if you’re so inclined) as a scheduled task.
At the heart of this is the powerful – though slightly inflexible – maven release plugin.
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.
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:
The updated source of the Spanners WS demo including the tests described here is available to download.
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.
Spring Web Services (Spring-WS) are a neat way of declaratively creating SOAP web services using Spring with a minimum of boilerplate code usually associated with web services. I’d recommend it as the best way to create web services for a Spring application. When it comes to WS-Security (message encryption, authentication, signatures and so on) it is absolutely vital. It simplifies the very complicated business of securing messages to a few lines of declarative code.
I found the documentation provided by Spring on writing Spring-WS services and securing Spring-WS services very in depth and thorough but I’ve not yet found a good simple example app. This demo is about the simplest possible web service with the most standard WS-Security features enabled.