jump to navigation

When designing a stub… July 4, 2007

Posted by Phill in General J2EE.
trackback

Stubs are quite common in J2EE applications: it seems quite common for J2EE to form a “middleware” layer which integrates between several different components. For example, the front-end page allows them to enter their login details, which then gets passed on to a third-party solution.

We’ve had the situation recently where we couldn’t have the third-party application available in our local test environment, so we had to write a stub. (Well, to be fair, other people wrote the stub – I just came along and used it!). It all worked well and good, and as the application was developed it went through comprehensive testing and passed.

This then went into our client’s test environment, which does contain a working version of the third party product. Guess what? It broke! Several times! The communication happens over an HTTP URL Connection: we send over XML, and the remote application returns some XML with the success or error code. Unfortunately, we’ve had the problem a couple of times now where the XML that we’ve been sending over is actually invalid: first of all, the date wasn’t being sent over in the correct format, and then it turned out there was an extraneous character in the XML (making it invalid).

Both of these problems could have been picked up by our stub being a bit more tight in what it would accept. At least coding it so that it validated the XML would have solved the second problem, and validating it against the expected input format would have fixed the first (even if it didn’t actually do any checking against a back-end).

So, my advice is: when designing a stub, make sure that it validates the input you give it, otherwise it’s pretty pointless having one!

Advertisements
%d bloggers like this: