It's really interesting what you say about automated tests. I completely agree that tests are generally non-existent in libraries, which is a shame as they often document how a library is supposed to be used when they do exist, as well as preventing bugs.
> ... document how a library is supposed to be used when they do exist ...
That will also depend on the library. In my library projects there is no way you'd figure out good/normal library usage because the vast majority of the test code is exploring edge cases and things that go wrong. I have 96-99% coverage which means there is a lot of non-normal usage tested. For example consider getting the length of something. Normal usage would just ask for it. Test code has to check different types, null pointers (if applicable), broken iterators, running out of memory and various other issues.
I do however have very comprehensive documentation including lots of example code. That of course is what the projects should provide rather than expecting reverse engineering of the test suite.
The reason for the exemplary unit testing in Ruby (it's not just Ruby... Python and other dynamic languages too) is that these languages do not have a compiler.
They have to unit test everything in order to catch bugs and not all bugs are caught by unit testing hence programs such as pylint try to do things that C++ compilers do every time the code is compiled. You can and should still unit test C++ code to make sure that data are as you expect, etc. A good compiler with all warnings turned on is very helpful.
