The gmock based unit tests generally don't expose race conditions and memory stomps. A good way to expose these is running libhdfs++ stress tests and tools under valgrind and pointing them at a real cluster. Right now the CI tools don't do that so bugs occasionally slip in and aren't caught until they cause trouble in applications that use libhdfs++ for HDFS access.
The reason the minidfscluster tests don't run under valgrind is because the GC and JIT compiler in the embedded JVM do things that look like errors to valgrind. I'd like to have these tests do some basic setup and then fork into two processes: one for the minidfscluster stuff and one for the libhdfs++ client test. A small amount of shared memory can be used to provide a place for the minidfscluster to stick the hdfsBuilder object that the client needs to get info about which port to connect to. Can also stick a condition variable there to let the minidfscluster know when it can shut down.