<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div>Hi Markus,</div><div><br class=""><blockquote type="cite" class=""><span style="font-family: Calibri, sans-serif; font-size: 11pt;" class="">The python unittest framework has a couple of advantages over the libtbx testing world. I found that the two most immediate advantages are:</span></blockquote></div><br class=""><div class="">my 2p: </div><div class=""><br class=""></div><div class="">First create a parallel testing bed which you trigger from the existing testing framework. That way, you don’t disturb anybody.</div><div class=""><br class=""></div><div class="">Then, please, use pick py.test instead. It is a far superior test framework, which can make intelligent use of plain asserts by magically providing some nice printouts when they fail. The amount of boiler plate required by unittest is too high imho. And then, I am pretty sure you could write a test runner which could find all the existing tests, if we eventually decide to move in that direction.</div><div class=""><br class=""></div><div class="">Which brings me to Pavel’s comments. I am definitively on his side. Yes, the cctbx does reinvent the wheel for its test system and in an ideal world we would be using more standard tools (I mean we reinvented the wheel for the build system too as we don’t use SCons as it is intended to). But the train has left the platform a long time ago: there is no way we will ever convert the existing tests to unittest classes. Hence my proposition to use py.test as this could make the transition painless.</div><div class=""><br class=""></div><div class="">Best wishes,</div><div class=""><br class=""></div><div class="">Luc</div><div class=""><br class=""></div></body></html>