Whenever I write an article exhorting people to do things the right way (or at least my way :), I like to appeal to their sense of pride. That usually doesn't work, so my next shot is laziness and a desire for entertainment. That's why this testing article spends so much time describing messy maintenance programming. It's only fun to really sick people.

There's one carrot already -- if you develop the habit of testing, it's much easier to maintain and to continue to develop your software.

Of course, a bigger demotivator is fear. Some people are afraid of change. Some people are afraid of learning new things. Some people are afraid of trying things on their own and need to have someone say, "It's okay to write a small test program to see exactly what happens." Some people are afraid of things they don't understand, and spend their time reimplementing something instead of reading its man page. (Fear can be a positive motivator too, but I advise against it.)

If the fear is "I don't understand testing", then a good and simple explanation (of good and acceptably simple tools) will help. If the fear is "I don't have time for testing", the proper response is "You don't have time not to test". If the fear is, "I'll be replacable", then hit him with a bus. (A toy one.)

That's a little more flippant than I intended, but the best way to approach this is cultural (peer pressure) and from a business value standpoint. If the manager can understand hidden and direct maintenance costs, there's a stick. (A good manager may be able to find a carrot there too.) If there's peer pressure to improve things, there's a carrot too.

If all that fails, get successively larger toy buses until he gets the point.