SPARQL support Tom comments about a number of things we have both learned since working at Tucana on making better software: "The unit tests are not unit tests. Most of the tests in Kowari are integration tests, that is, while they may test only a single class, they test that class with the roles of its dependent class filled by real concrete instances, rather than mocks...Andrew and I have been bitten by the agile, quality, TDD and refactoring bug, and having our own small project to play with makes this much easier. It also allows us to enforce higher standards on the codebase as there's only two of us that need to agree at the moment."
"I hope none of this comes off as criticism for Kowari as this wasn't my intention. It's certainly the best triplestore there is, and the project is moving ahead at great guns now. It's basically a reflection that Kowari is too heavyweight to do what we want to do and that both projects have different goals."
The difference in what is a unit test is significant, Martin Fowler's "Mocks Aren't Stubs" is a good introduction - although he remains on the fence. We didn't - we used interaction based testing throughout. We still had the usual integration tests but it also included environment, wiring (Spring), and others. Interaction based testing seems to lead to better software. We even test drove XML, properties, etc.
How the software is better is not in the quality code so much (although I do think the initial number defects is also lower) but in the health of the code. A healthy code base can respond quickly to changes in architecture, requirements, etc. or in other, trendier words - it's more agile. Kent Beck's talk on software health is well summarized here.
Paul O'Keeffe and Greg Davis gave a presentation on Sustainable Software Development - firmly on the interaction testing side. You really do seem to get benefits late in a project with a sustainable, healthy code base.
I think it's covered in, "Using Software Maintainability Models to Track Code Health" but it doesn't seem to be available online. Another paper though, Software Deterioration And Maintainability – A Model Proposal contrasts the difference between "fast hack" and a "controlled update" for example and the need for just the right amount of effort for maintaining software. Finding research on interaction versus state based testing would be interesting.
JRDF still needs refactoring to get into a stage where it is test driven. And test driving isn't always a good tool to develop solutions to problems (to hack, to spike). So there's still a place for that too.
No comments:
Post a Comment