[Dovecot] a proposal to increase the stability

[Brian Bartholomew]

You'll probably also want to redesign dovecot a bit for testability.
In the electrical engineering world, this means bringing important
circuit nodes that are functional chokepoints to the outside of the
package where test equipment can be attached to them.  It also means
adding a way around some layers of external interface, so the core
functionality can be attached to a "life support system" where all of
its inputs and outputs, now reworked into convenient test plugs and
sockets, can be controlled at once by the "test harness".

In the software world, it works the same way.  If there's an important
state machine at the core of dovecot, make its state directly readable
and writable.  You may want to write some state-flushing and loading
functions so that you can quickly reset to a known state, or step
forward to a given state without going through a bunch of intermediate
states.  The external interface you might remove for dovecot would be
the socket interface, so that you can test ten different versions of
dovecot at once, on the same machine, under automated control, without
any of them colliding on pathnames or IP ports.

You'll find redesign for testing has the beneficial side effect of
cleaning up the interfaces within pieces of the core, and finding and
removing linkages you didn't realize were there and didn't want.

For projects larger than dovecot, design for testability ends up
embeding a scripting language into the application (don't write one,
use guile, perl, or tcl) for greater control of internal pieces/parts.
In a small C application like dovecot, you may get somewhere by
inspecting internal state with gdb and full symbols rather than a
scripting language.  Send this verb in the input, check that internal
variable with gdb, read the contents of that Maildir file.  Because
the test is automated, it can be added to the compile, build, and
install scripts.  You get to a point where you are testing the same
functionality from several different viewpoints, and then it's hard
for bugs to creep in without lots of warning from tests failing.

Enjoy!
							Brian