After some struggling, we managed to get our build file working this morning. “Owned! Devs 1, Build File 0”, I thought.

It’s an odd expression, “Owned”, commonly used by gamers and people who read too much PvP. It’s used to express one’s mastery over an opponent in-game, as in, “Ha! I got you with the rocket in midair! You were everywhere! You’re nothing but pieces! I so owned you!” And so forth, though usually with numbers instead of letters.

In this instance, with the slightly less gory game of “Forcing the Build File to Build Things”, the expression “Owned” seemed surprisingly apt. We had managed to get into a position where were were servicing the build file regularly, checking it and pandering to its quirks. It owned us. We were its slaves, even though we were also its creators. We made it to give us an easier life; to provide us with a service. Somehow the roles got reversed. We’ve coerced it into doing its job for a day, but who knows what will happen tomorrow? Will it still behave? or will it, like Homer’s monkey in the Simpsons, lie beered up on the couch, spreading its mess across the room while we run around after it fetching it peanuts every half hour?

I’m firmly on the side of test-driven tools, including Ant Builds. A complex build file often gets changed and altered more than any single piece of the code it builds, and it’s just a domain-specific language, after all. I don’t know how to test it, or what alternatives exist, but I intend to find out. Maybe you can tell me. Somewhere out there is a harness I can use to control these things.

How much of your code do you really own – and how much owns you?

This entry was posted in Uncategorized. Bookmark the permalink.

7 Responses to Owned!

  1. icklemichael says:

    This isn’t something I do, but you should be able to knock up some testing in ant easy enough, eg (I just wrote this off the top of my head, you can probably make it better).

    <?xml version="1.0" encoding="UTF-8"?>
    <project name="example" default="all" basedir=".">
        <target name="all" depends="foo"/>
        <target name="test-build" depends="assert_foo"/>
        <target name="foo">
            <touch file="foo"/>
        <target name="test_foo" depends="foo">
            <condition property="foo.created">
                <available file="foo"/>
        <target name="assert_foo" depends="test_foo" unless="foo.created">
            <fail>'foo' was not created</fail>

    With the ‘if’ task from ant-contrib this would probably be cleaner, maybe.

  2. sirenian says:

    I think the problem is that ‘foo’ actually creates files, etc.

    I want some way to test the script without, say, deploying the project’s entire build to the server. This is particularly appropriate if you’re going to use the test along with continuous integration a la Cruise Control, ie: every time you check in, all the tests are run.

    Maybe I could make a kind of ‘mock’ ant library by replacing all the tasks with stubs which just stub the file creation, etc., and output a report on what’s happened.

    Maybe we should just use Ruby scripts instead…

  3. icklemichael says:

    In my mind, if I was testing something that updated a database, I’d use hsql and set up the database into a known state before the test run and check it got to where it needed to be afterwards.

    If I thought it would achieve anything I’d do the same for the build process, give it a file system of known state (and app server if your build system actually does deployment – ours doesn’t), and then let it actually go and do whatever it does and check it at the end.

    I suspect this is a difference in philosophy though, you’d probably use a mock jdbc driver and check that it sent the right SQL to the database [1].

    [1] Apologies if this is a poor characterisation of behaviour testing.

  4. anonymous says:

    Inspired by Martin’s article and a distaste for NAnt I started doing some work with Rake recently. I really like it quite a bit and would recommend it to anyone. I’ve written several blog entries recently on rake, but they are more .net focused. I’m sure using it for Java would be just as easy or easier, so give it a try.


  5. anonymous says:

    I think there’s an opportunity here for someone to produce Rake equivalents of the standard Ant tasks: http://ant.apache.org/manual/coretasklist.html and plug them together in an easy to install package. Add in documentation (with examples that are good enough to copy-paste) and we could start to see some disruptive innovation in build systems.

    If someone does do this then it should become relatively easy to just declare that your build should leave you with the following artefacts and that the absence of these artefacts indicates that your build file/environment is now incorrect.

    I don’t feel there’s much value in TDD with your build but there’s a lot of value in being able to specify that that your build file must always satisfy a set of constraints (artefacts generated, time taken, etc). This is one of those places where design by contract might be preferrable to TDD. But this is pure speculation.

    Moving to a proper programming language would be preferrable to following in the footsteps of Perl and Php (two languages that evolved from being a rough assemblage of tools) till we end up with a full-blown Ant programming language. It also means that we can start having more reuse between build scripts and start making integration builds (where the artefacts from multiple projects are automatically built, collected, deployed together and then tested) easier to do.

  6. sirenian says:

    Normally I dependency-inject the database services via interface, then stub them out completely – no need for mock jdbc anything.

    I don’t do “behaviour testing”, just “behaviour driven design” – which means writing descriptions of behaviour and using those descriptions to drive the code. You might call the descriptions ‘tests’ if you were using JUnit, but really, the whole concept of ‘test’ is misleading if you’re writing test-first.

    I’d probably use some kind of proven persistence mechanism, dependency-inject it via interface then ignore the database completely. We’ve done that on previous projects, at least at the unit level.

    That’s what I mean, though; frameworks like that are available for Java, but not for Ant etc. I think your approach might be the way forward, but I have no idea how to check if an .ear file containing a .war and a .jar does in fact have all its little components in the right place, unless I unjar everything.

    More particularly, I want a quick way of telling if a refactoring of an Ant file has broken it!

  7. sirenian says:

    Rake is now on my list of “things I have to look at”.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s