Patterns of Human Error - my presentation at the DC ACM

[bearophile]

Kagamin:

> What do you think about unittesting efficiency section?

I always use unit testing, in Python I especially like doctests. But often unit tests aren't enough, so I use Contracts too. Type system-based solutions too help, a quotation I've read elsewhere (written by a Haskell programmer):

>Rather, what you need is a way to make deep structural changes to your code, and still end up with a fair amount of confidence that the result is at least reasonable, that you haven’t forgotten something big. Unit testing won’t do the job; there are just too many false failures, since making such a large change tends to invalidate huge swaths of your unit tests anyway.  You already know that they won’t work, because you deleted or changed the arguments to the pieces that you were testing.  Indeed, while test-driven development works great for the vast majority of programming tasks that fall squarely in the "not difficult" category, it has a tendency to crystallize the code a bit quickly here.  You don't want to be told about and need to fix every place something changed; you want to know specifically when you've made changes that are not consistent between themselves. That, of course, is the job of a type system.<

On the other unit tests are about single functions, and often small leaf-functions don't need to change if you change other parts of your program, so their tests don't need to change.

Generally you use all tools you have to increase the probability your code is correct.

Bye,
bearophile