[TIP] structure of a testing talk

[Mark Sienkiewicz]

On 10/03/12 05:14, andrea crotti wrote:
> Well not exactly, I'm speaking to experienced C developers, so probably not
> worth to talk about exoteric things ;) One thing which I think is important
> is to explain that the important skill is not much writing tests, but
> writing code that it's easy to test..
>


The buzzword is "Design for Test", and it is a big deal in hardware.  I suggest you give it a top-level bullet point in your presentation.  Instead of mentioning it at the end, mention it at the beginning and use it in your examples.  You want to be talking about something else and then then say "by the way, see how this thing I am testing was designed to be easy to test?".

If you can, include at least one example where the software would be hard to test, except that it has a specific test featurein it.  (Yes, it's hard to make a simple example.)


b.t.w.  In your outline, the one thing that stands out for me is "Side effects, and why they are bad".  I think you might lose a lot of C programmers by saying it that way, because a lot of C code exists _specifically_ _for_ the side effects.  write() is only useful because of the side-effect, for example, and we have exactly the same function in python.  Saying "side effects are bad" may turn off your audience and make them less able/willing to listen to the rest of what you have to say.

In your presentation, funcs.silly_function() appears to generate blocks of serial numbers (though you are only asking for blocks containing 1 serial number in your example).  Can you explain to a C programmer what exactly is bad about a function that returns a unique serial number every time you call it?  I wouldn't bother talking about a singleton serial number object, because a C programmer will immediately recognize that as the same thing.

Instead, I think you want to talk about appropriateness of side effects.  It can be easy to pack weird side-effects into all your functions; then you have a system that is hard to understand.  Narrowly, carefully, and clearly defined side effects are good; random, arbitrary, or confusing side effects are bad.

You can integrate this idea into the design-for-test model.  When you have side effects, you have to have a way to determine if they happened.  This means both an interface to peek into <whatever> to see if the side effect happened, and a clear definition of what was _supposed_ to happen.  You can be motivated to write more purely functional code because it will be so much easier to understand and to test.

Mark S.