I should add that we do, eventually, want good coverage of our API with example code. However, that coverage just has to be thorough enough so that any any usage can be figured out trivially, no so that any function can be called by cutting a pasting a particular line of code.
It might be worth adding a examples directory at some point. Personally, I would really like it if the examples were built and run as part of the test suite and their output checked, just so that we know they are always working.
On Dec 12, 2007, at 5:23 PM, Daniel Russel wrote:
>> or the existing test cases are not really unit >> tests. Unit tests should be on the smallest practical units, >> otherwise >> your methods can change without breaking the tests while some poor >> user >> using your methods will have their code break. > > How does it help if a unit test specifically calls a particular piece > of API as opposed to the API is used internally? > In both cases the API is being tested similarly thoroughly. > > If I want to change the API, in both cases I change the class and then > change some bit of code somewhere calling it. In either case, the the > user is screwed if documentation of the change does not make it to > them somehow. It only makes a difference if users are monitoring unit > tests for evidence of changes. I have trouble imaging anyone doing > that given that we have the doxygen docs and a commit list (and > eventually, presumably, nice a human readable list of changes). > > And given the current state of our unit test code, I hope no user > looks at them for anything. > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev