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
https://salilab.org/mailman/listinfo/imp-dev