Testing, testing, 1-2-3…

Lately, I've been thinking about testing a lot. Thomas Duff has had some interesting things to say about the XP approach, which is (amongst other things) test-driven.

Naturally, there's been some pondering about how one can practically apply this to Notes & Domino programming — in fact, I feel an article coming on soon (it's about bloody time!) Essentially, test-driven development is all about writing the tests first, rather than diving straight in with the code. Sounds odd at first, but bear with me. Suppose you have a new application or problem to sort out. It could be complex, and you don't really know where to begin in terms of structuring your code (whether that's organising a load of procedural routines or designing an object model). Designing applications is an art, so anything that helps structure one's thoughts can't be bad eh? This is where your tests come in: write those first, and this will help lend a semblance of structure to your solution. In addition, knowing that each component comes from a test scenario means that it gets tested during coding rather than after. Ideally you're then in a position to combine your components into the finished solution with confidence: all your routines / classes / whatever have been through the testing process multiple times.

I'd also add that this approach means that you have more of a chance at avoiding those really stupid design errors, made when you're just too close to your code (or is that just me? :-o)

Does anyone else have thoughts on this?


  1. I'm thrilled to see the subject of XP getting discussed on the blogs, as well as the specific topic of XP-type testing within Domino. Richard Schwartz is also interested in this slant, and I look forward to seeing where this all leads.

    Thanks for bringing it up, BENThomas Duff#
  2. LOL (explanation: Discussion at Julian's site

    Looking forward to the e-Pro article Tom!Ben Poole#
  3. So am I… I need to follow up with Libby to see if there's a new date as to when that will be published (or if it's still on). If not, I'll post it on my site.Thomas Duff#
  4. Been there, done that - got the t-shirt…. XP and DominoJens-Christian Fischer#
  5. i really don't understand why you guys are so excited about Windows XP.

    (snork) ;-Pjonvon#
  6. Ahhrg - not XP but XPJens-Christian Fischer#
  7. I'm currently starting out on version 3 of a part of our system. Version 1 was, well, version 1, and had its failings. A year later I wrote version 2, with a bit more insight and OO experience, but the functionality is rather complex, and we knew the 'traditional' testing was going to be so hectic, that we kept putting it off until bitrot meant we couldn't roll it out. Nearly 10 libraries of unused code [smiley frown]

    With version 3 (more insight, new requirements, more OO experience), I'm trying to think of ways to do more low-level componentised testing, but it's not easy.

    I think there are 2 big issues:
    1) writing good tests -- some things are 'general' and easy to build unit tests… others, you run the risk of simply writing alternative 'wrappers' which do the same thing as the original client code.
    2) DISCIPLINE… I've always written small 'test' routines & agents to test bits of bigger systems (nothing on the level XP seems to suggest, though), but as the code morphs, a lot of these fall by the wayside. Making sure that the 'test' code doesn't get left behind, and committing to test-first, test-at-each-change needs a serious commitment.

    Thanks for the post, you guys are getting me to think a lot more seriously about this testing. I see serious benefits but I'm still not 100% sure how to get there… but I'll be doing a lot more reading.Colin Pretorius#
  8. Some of my thoughts in this thread ( in my blog. I'll bet that somewhere "out there", there are quite a few more people who have given some thought, and maybe some experimentation, to the idea of XP and Domino. We need a good way to get the word out and start collecting the good and the bad.

    -richRichard Schwartz#
  9. The idea of building test cases while designing or coding is certainly not new. Heck that's what they were teaching back in my college classes in mid-80's in a COBOL environment! And Microsoft and Lotus in the development practices that they at least were preaching 5 or more years ago, suggested kind of 'proto-cycling' and documenting as you go (which in my mind includes test cases, but I don't recall if that was in the 'official' course from MS).

    What's different in XP, of course, is the idea of a couple of folks sitting together and cranking on the coding and test cases. I've done the XP-style of coding at times, although we didn't call it that, and it wasn't for more than short spurts. However it is very quickly apparent that there are benefits to be had.

    As for HOW to do automated testing…There at least USED to be some tools that would help this type of thing. Years back I coded some routines using a tool called AUTOMATORmi (I think). There was also a tool from them or someone else with the word GHOST in it. These were basically macro record/playback tools with logging. You would manually do whatever you needed to with an app, recording a macro (just like recording a macro in Word or Excel). That macro could be saved as your test module, and run when needed, recording whether or not the results met the expected results. OK, that was limited to Windows systems and things like mouse movements raise all kinds of problems, but the point is that I'm certain there are tools available. It would make a GREAT article for one of us to research automated testing tools for Notes/Domino and publish the findings.Joe Litton#

Comments on this post are now closed.


I’m a software architect / developer / general IT wrangler specialising in web, mobile web and middleware using things like node.js, Java, C#, PHP, HTML5 and more.

Best described as a simpleton, but kindly. You can read more here.