All posts by evan

Customer Experience Improvement Program

The new version of messenger comes with a big fat link at the top of the contact list titled “Click here to join the Customer Experience Improvement Program”. They have invited me to join the program to help them collect anonymous information about my hardware configuration, and how I use their software and services. Errr.

Do I click on “I want to help make Microsoft software and service even better (Recommended)” or “I don’t want to right now”? I wonder.

Is this for real?

Total Eclipse

Have picked up a couple more Eclipse plugins worth having:

  • JNDI Browser – provides a nifty tree browser for your JNDI directory
  • Solar Eclipse – not as good an XML editor as XML Buddy, but it does JSP syntax highlighting
  • Mock Maker – generation of mock object implementations from interfaces and classes
  • I also worked out today that eclipse zips along a bit faster if you disable the plugin development features while you aren’t using them, and turn off the “Link Navigator selection to active editor” setting (for both general workbench and java). Much better.

    Mock Testing

    My head hurts. Have spent most of the afternoon starting to introduce mock object testing to my project. Not being ‘test infected’ to perfection I’ve been happily prototyping away without writing tests first for a couple of weeks, so introducing tests was going to be a chore anyway. I started off using cactus to write some server side tests as I’ve done in the past, however this path soon became very frustrating and slow.

    Background: part of this project involves hooking up to the proprietary RMI interface of a 3rd party application in order to execute queries against their persisted object store and extract data for reporting purposes.

    In order to test the classes that perform the queries using cactus requires BOTH an active instance of the 3rd party app, and for my app server to be running. Test data issues alone are enough to make me hurl. Ugh. Time to reach for mock objects, which I’ve been considering for some time.

    First what I needed were mock object implementations of the 3rd party classes that are accessed by my code. I downloaded the nifty mockmaker plugin for eclipse. Apart from a few glitches with package names and imports, this works well at creating mock implementations ready for me to use.

    Next I needed to refactor a lot of my methods to allow me to pass in the mock objects, rather than create them in the code with the new operator or call static factory methods. This lets me unit test those methods directly by setting up mock objects and passing them to the method. I kind of think of this as delegating the decision about actual implementation further up the chain of command. This was actually a big shift in thinking for me – one I’m not convinced about yet.

    What I realised when setting up the mock objects for my test is just how unnecessarily over-dependant my design was on the 3rd party API. Every step would have involved more and more mock implementations and much more code to set them up to be called. What I needed to do was push more of those dependancies into my adapter layer, and simplify the interfaces as much as possible. This decoupling lets me reduce the amount of mock object code required dramatically, and I think my design is going forward really nicely.

    What am I not completely comfortable with?

    1. My adapter layer is quite heavily coupled to the 3rd party API. To mock test this layer would require a lot more work – I think I’ll have to test that using cactus and those test will be slow, data-dependant, and require an active instance to be running.

    2. Instantiation of the objects that I’m mocking (outside of the 3rd party API) will HAVE to be done somewhere. My current strategy will be to place that instantiation within methods that don’t perform any other function than to perform instantiation (or call factory methods) and then pass responsibility to the tested method. Example:

    public drink(Beer input, Urinal output) {

    output.append(input.sumUnits());

    }

    public drink(Beer input) {

    Urinal output = Urine.getUrinal();

    drink(input, output);

    }

    The first method contains the actual implementation, but is ready to be passed a mock input and output for testing. The second method implements the interface that I want to be used by the rest of the system, as I don’t want to pass the urinal around.

    Not sure I’m real happy about that either – will make refactoring a bitch. Another alternative might be to create some sort of environment Hashmap that contains the resources required and pass it around between methods. Would be interested to see other people’s strategies.

    ion CMS

    Check out ion CMS. It’s basic features for content editing, publishing and workflow are comprehensive and friendly (and NICE to work with from an authoring perspective). Under the hood it uses struts templates and the JSTL – I’ve moved away from struts towards webwork recently, but there’s nothing here that’s scary. I mean scary as in “but how will this integrate with my …”.

    The ion project is an effort to provide a very simple but powerful content management system based on the most recents technologies. Ion is 100% compliant with J2EE standards, uses XML to define contents structures, XSL to provide rendered contents in many format (HTML, XML, PDF, TXT, …), and JSP with JSTL as a template system.

    It also uses osworkflow which is how I got there in the first place…

    Switch to JBoss 3.04

    Switched development platform from Orion 1.6.0 to JBoss 3.04 this afternoon. Took about an hour, mainly because Jetty will not run with <distributable/> in web.xml. XDoclet puts a <distributable/> tag in there by default. Took a lot of forum-trawling to find that answer. Initial impressions are good – I was battling with JBoss 3 Alpha a few months ago and eventually gave up, but I’m glad to be back. Orion just seems to be stagnant – how long has the 1.6.0 release been sitting there going nowhere? It also seems a bit flakey – certainly won’t support hot redeployment – just errors every time.

    Hope OC4J is in better shape…