Diez B. Roggisch wrote: > Sounds good to me. IMHO there are two ways one gathers tests: > > - concrete bugs appear, and one writes a test that reproduces the bug & > eventually after the fix runs smoothly > > - new features are planned/implemented, and the tests accompany them right > from the start, to allow .. .well, to test them :) > > I always found it difficult to "just think" of new tests. Of course if you > _start_ with TDD, point two is applied right from the start and should > apply.
an approach that works for me is to start by adding "sanity checks"; that is, straightforward test code that simply imports all modules, instantiates objects, calls the important methods with common argument types/counts, etc, to make sure that the library isn't entirely braindead. this has a bunch of advantages: - it gets you started with very little effort (especially if you use doctest; just tinker a little at the interactive prompt, and you have a first version) - it gives you a basic structure which makes it easier to add more detailed tests - it gives you immediate design feedback -- if it's difficult to think of a even a simple test, is the design really optimal? - it quickly catches build and installation issues during future development (including refactoring). and probably a few more things that I cannot think of right now. </F> -- http://mail.python.org/mailman/listinfo/python-list
