If you want to test queue-size limits under plausible conditions set up more-than-two consumers and more-than-two producers with random rates of speed from cycle to cycle but some known to be faster/slower than the others. Provide some way for the process to know that it was or was not blocked during its last request (and test that code too). Let one thread launch this test case, wait for them to finish and then judge the scores (how much sent/received, how many times blocked due to empty or full) by some heuristic that is not absolute. Fast producers and fast consumers should have run against limits; slow consumers in the presence of (only) fast producers probably not. No outcome absolutely deterministic, but you can deduce whether the outcomes are plausible or not. Vary the above description according to exactly what your package is or is not designed to be capable of.