The FilePath library is based on the idea that all functions must satisfy a list of properties, which are documented in the interface. I use QuickCheck to automatically test that these properties hold. This leads to the great situation where there are only two classes of bug:
- A property is wrong
- A property is missing
Once the properties have been decided upon, and having left a night to see if anyone had any other thoughts on the properties, the coding can begin. This then makes the process of coding much less hacky, and much more precise:
- Write out the properties
- Write out code to implement them
- If the tests fail, you have a counter example - go back to 2
- Done
By the time you get to 4, the code meets the properties. You have already done 1000's of tests (more than 10,000 in FilePath) and can have a fairly strong degree of confidence in the work you have produced. The bug reporter has already agreed with the changes you've made, even before you've made them.
I have never done a library before so focused on properties, but it has had amazing advantages. The advantage of having correct and reliable code may be obvious - but in practice the amount of confidence in the code surprised me. By far the bigger benefit has been collaboration - the very high declarative nature of properties makes them something well suited to "group thought".
3 comments:
I followed the link to the FilePath docs. Question: when you say
dropExtension :: FilePath -> FilePath
Remove last extension, and any . following it.
dropExtension x == fst (splitExtension x)
shouldn't that be:
dropExtension :: FilePath -> FilePath
Remove last extension, and the "." preceding it.
dropExtension x == fst (splitExtension x)
based on the definition of spitExtension?
Good catch Gregor! I've updated the documentation, it was just a verbal typo that is beyond the range of QuickCheck
This is a well-known (but sadly underused) practice typically referred to as "design by contract". It is a very powerful way to control the quality of a system when quality can be easily expressed in terms of invariants and conditional properties, as you describe.
Unfortunately, it's not really Nirvana - the next cycle of reincarnation involves a project where the quality constraints cannot be fully expressed as a contract ;-)
Post a Comment