[TIP] Talking to a test-is-from-outer-space crowd

[Mark Sienkiewicz]

Alfredo Deza wrote:
>
> But programming is hard too. So it shouldn't matter that UnitTest 
> *might* be difficult to grasp. If you want to get better
> you might as well get used to learning things that are not easy to 
> understand at first.

I mostly agree, but not with this part.  You can't teach people by 
throwing all the complexity at them at once.  If you want to make a 
beginner try to avoid testing whenever possible, force them to 
concentrate on the mechanics of using unittest instead of the benefits 
of testing.

For a beginner, you want a simplified system.  Did you ever study 
introductory physics or calculus and solve the problem where you drop a 
ball from a certain height and find when it hits the ground?  The 
problem is always "neglecting air resistance" because dynamic friction 
makes the problem too complicated for a beginner.

But how can we make tests simple enough for a beginner?  Consider this 
test that works in nose:

    def test_1() :
       x = add(1,1)
       assert x == 2

A beginning programmer can understand this.  They don't need to think 
about "fixtures" or "suites" or "test cases" or "runners" or even how 
object inheritance works.  You can start teaching somebody to program in 
python, and on the first day they can write tests for their very first 
program.

Someday, when they become more experienced, maybe you can show them a 
benefit to unittest.  But when that day comes, you don't have to 
persuade them that testing is a good idea -- they will already know 
that.  Instead, you can concentrate on the question at hand:  Why should 
I use unittest?  What does it do for me that I can't do more easily in 
some other way?  How does this complicated thing work?

Nobody ever tries to present a "steep learning curve" as an advantage, 
because we know systems like that are hard to use and people want to 
avoid using them.  People find new material much more accessible if you 
structure it as a series of smaller steps.

Mark S.