October 22, 2004


OMR was used by 8085 students in the first three weeks of term, including part-time students for the first time. It handed most students' registrations without problem, but there were a small number of problems that affected students. Of these, virtually all were due to departments not making up their minds what modules should be available (and with what cats scores and assessment methods) until well into term. This appears to be a deeply ingrained political problem, which never mattered much when all module registrations were captured on paper and could be sorted out over the following months. But now that there's an IT system to do this, the system needs to know what modules are running!

There were a small but irritating number of problems on the staff view side, caused by relational integrity problems in the database. These were due to a bug in a JDO superclass that I discovered late in September – the bug had been there for a year, but this was the first September that the system had been live and the very obscure set of circumstances when it did the wrong thing had never come up before. This was a sufficently fundamental part of the system that I had written unit tests for it, which reinforces my view that unit tests are not very good for testing correctness, especially written by the same person who wrote the code they're testing – they only test the object the way the author thinks it's going to be used. What unit tests are good for is regression testing: making sure you don't break something that used to work a particular way – even if that is not actually correct.

- One comment Not publicly viewable

  1. Chris May

    Unit tests are not very good for testing correctness [...] What unit tests are good for is regression testing:

    I think that's largely true; with the addition that unit tests can also be good for designing the interfaces of a class. I've never managed to do a 'full' test-first design, but I have found that if I start to write unit tests as soon as I have the outline of an interface, then I can discover the bugs and edge cases in the interfaces faster than if I just dive in and start writing the implementation and the first client of the interface.

    I'm not wholly convinced that you can test for correctness. You can design for it, and you can inspect for it, but any kind of scenario-based testing will always fall foul of the fact that the number of possible scenarios for even a trivial class is as near to infinite as makes no difference.

    22 Oct 2004, 13:39

Add a comment

You are not allowed to comment on this entry as it has restricted commenting permissions.

October 2004

Mo Tu We Th Fr Sa Su
Sep |  Today  | Nov
            1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31

Search this blog



Most recent comments

  • Good luck, Jon. Thanks for your helps in the past 3 years. by Hongfeng Sun on this entry
  • Good luck in the future by Mathew Mannion on this entry
  • It is indeed. And when I look out of the nearest window at work, I see Charter Avenue, where parking… by on this entry
  • There's very little free parking on the rest of campus, so why should westwood be treated favourably… by on this entry
  • I live in Earlsdon. I can drive, but haven't since I came to University here in 1990 (I never left –… by on this entry

Blog archive

Not signed in
Sign in

Powered by BlogBuilder