Hi Michael<br><br><div class="gmail_quote">On Mon, Sep 27, 2010 at 12:50 PM, Michael Foord <span dir="ltr">&lt;<a href="mailto:fuzzyman@voidspace.org.uk" target="_blank">fuzzyman@voidspace.org.uk</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



  
    
  
  <div bgcolor="#ffffff" text="#000000"><div>
    On 26/09/2010 19:43, Arve Knudsen wrote:
    <blockquote type="cite">Hi
      <div><br>
      </div>
      <div>As I&#39;ve been tinkering with nose2 and unittest2, and got to
        know the two better, the question has emerged as to exactly
        which role nose2 is meant to fulfill on top of unittest2.</div>
      <div><br>
      </div>
      <div>With the original unittest, nose&#39;s raison de vivre is pretty
        clear; seeing as unittest is rather an archaic/inflexible
        framework, there is an obvious need of a more modern, practical
        alternative. nose offers such an improved alternative. unittest2
        on the other hand changes the game, as it is being designed with
        today&#39;s needs in mind, and is plugin-based (like nose). That
        unittest2 is a sound design is evidenced by the fact that nose2
        implements its functionality as unittest2 plugins.</div>
      <div><br>
      </div>
    </blockquote>
    <br></div>
    Hello Arve,<br>
    <br>
    Well, presuming to speak for Jason here (partly)... My
    understanding, as author of the unittest2 plugins code, is as
    follows.<br>
    <br>
    The purpose of the plugins machinery being developed for unittest2
    is to *allow* useful popular and frequently requested functionality
    for unittest (such as that provided by nose) to be provided in clean
    and simple ways. The plugins branch itself is not *intended* to
    replace nose - merely make it dramatically simpler to implement and
    maintain. That at least is the goal.<br>
    <br>
    The situation is confused by the fact that in order to ensure the
    plugins branch meets its goal I have implemented various &#39;example&#39;
    plugins that have some overlap with the nose functionality.
    *However*, these plugins only cover a relatively small subset of the
    nose functionality.<br>
    <br>
    The purpose of nose2 is to provide the functionality of nose using
    unittest2 plugins. This includes goals like, wherever possible,
    backwards compatibility with existing nose tests. (But not existing
    nose plugins as the mechanisms are too different.) </div></blockquote><div><br></div><div>OK, I guess that maintaining compatibility with legacy nose tests is the distinguishing point here. I wasn&#39;t aware of that particular design goal.</div>

<div><br></div><div>Personally I&#39;d like to see the need for 3rdparty unittest(2) wrappers to go away, for most uses. What I *think* unittest2 should provide is a (more or less) state-of-the-art test runner, with a sensible set of basic functionality, and the ability to be extended with extra functionality. </div>
<div><br></div><div>Thanks to you and Jason&#39;s information, I can now see that nose2 only configures the unittest2 runner with nose2 plugins. Thus, nose2 is really a unittest2 plugin suite with a specific purpose (reimplement nose).</div>
<div><br></div><div>How about a general way of installing unittest2 plugins so they are automatically detected by the unit2 runner? This is how I&#39;d like to be using unittest2 I think; the runner gives me all the control I need (for example, stop on first failure) and I can extend it with the domain-specific functionality that I need (e.g., coverage analysis). Hudson is a good analogue in this regard IMO; it&#39;s an excellent basic CI system, but domain-specific functionality (e.g. Git integration) is implemented through plugins. This design works superbly in practice, I might add :)</div>
<div><br></div><div>Cheers,</div><div>Arve</div></div>