There have been tentatives to create nose plugins which test results in a simple fortma, one of them being NoseXunit; which generates JUnit-compatible format for test results.<div><br><div class="gmail_quote">On Sun, Apr 5, 2009 at 5:40 PM, Douglas Philips <span dir="ltr">&lt;<a href="mailto:dgou@mac.com">dgou@mac.com</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">On or about 2009 Apr 5, at 10:38 AM, Michael Foord indited:<br>
<div class="im">&gt; We use a custom TestResult with unittest to push results into a<br>
&gt; database whilst the tests are still running. Once the results are in<br>
&gt; a database building custom reporting tools is much easier.<br>
<br>
</div>Understood. From the discussions at pycon there seemed to be interest<br>
in having a common results format across many testing tools so that<br>
&quot;we&quot; could build up a suite/eco-system of result processing tools that<br>
would be decoupled from the particular tool(s) being used to generate<br>
the results.<br>
<br>
I&#39;ve thought about using a database in the manner you suggest, but I<br>
have to admit some concern over the coupling there too. Not just in<br>
terms of &quot;SQL&quot; noise (to be fast and loose with terminology), but also<br>
in the potential fragility of what would happen to my test runner if<br>
the reporting mechanism were to hang or break.<br>
Our current test log output format was designed to be easily flat-file-<br>
processable after the fact. Reality is that we haven&#39;t (yet) written<br>
any of those tools. My instinct for simplicity says that I want to<br>
keep the regression test runner simple, and be able to plug it in to<br>
any number of back ends. One of things that I don&#39;t like about<br>
unittest is that (at least in 2.4.4), there is a lot of intertangled<br>
hair between the components, the text test runner does too much. (I&#39;ve<br>
heard rumors that there is unittest work on the cusp of being<br>
released, but I don&#39;t (yet) know what the result of that work is.)<br>
<br>
My impulse is to see if there is leverage with having a simple (TAP-<br>
like?) output format which can then be plugged into test result<br>
processing pipelines. One of those pipelines could start with<br>
injecting the results into a database, but I&#39;m leary of having that be<br>
part and parcel of the test running infrastructure itself.<br>
<div><div></div><div class="h5"><br>
-Doug<br>
<br>
<br>
_______________________________________________<br>
testing-in-python mailing list<br>
<a href="mailto:testing-in-python@lists.idyll.org">testing-in-python@lists.idyll.org</a><br>
<a href="http://lists.idyll.org/listinfo/testing-in-python" target="_blank">http://lists.idyll.org/listinfo/testing-in-python</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Laurent Ploix<br><br><a href="http://lauploix.blogspot.com/">http://lauploix.blogspot.com/</a><br>
</div>