Test-driven development and code size

[Fredrik Lundh]

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>