<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<br>
Douglas Philips wrote:
<blockquote cite="mid:906DBAA1-30A8-4FC0-A2CE-89AFD8A584B1@mac.com"
 type="cite">
  <pre wrap="">On or about 2009 Apr 22, at 9:45 AM, Ned Batchelder indited:
  </pre>
  <br>
  <blockquote type="cite">
    <pre wrap="">more complex.  The natural impulse is to factor common complexity  
out of
the tests into something else.  That other thing is the test  
framework.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Maybe, or maybe just some intermediate places. It depends on how you  
define 'framework.' In my case, we have a customized version of  
unittest where the most general abstractions live, but then we also  
have other layers of TestCase subclasses which only apply to certain  
kinds of tests. I would not classify those intermediate subclasses as  
part of the framework since they aren't general enough. Just saying  
that isn't so black and white and "in the test or in the framework." :)

  </pre>
</blockquote>
You are right, and I was confused by the terminology in this thread
too.&nbsp; My interpretation is that we are talking here about complexity in
the project-specific code common to all tests.&nbsp; Titus called that his
"test runner" in the original post, and others morphed it into "test
framework", but it all only makes sense if we take it to mean the code
in the project to support the tests.&nbsp; Not the tests themselves, and not
a third party test framework like unittest, py.test or nose.&nbsp; Your
"intermediate place" is the place that we're all talking about. I think!<br>
<br>
<blockquote cite="mid:906DBAA1-30A8-4FC0-A2CE-89AFD8A584B1@mac.com"
 type="cite">
  <pre wrap=""></pre>
  <blockquote type="cite">
    <pre wrap="">Then you don't have to maintain it, but you still get to benefit  
from its power.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
There is lots of power in nose and py.test that I. do. not. need. I do  
not benefit from it. I am hurt by it, and thus I have, to date, chosen  
not to use it. The ROI is way too low. Can't speak for Titus.

  </pre>
</blockquote>
Maybe you could give us an example of complexity in nose (to pick a
concrete example) that you didn't need, and how it hurt you for nose to
have it?&nbsp; We tool builders often assume that it's OK to add features so
long as they can be ignored by those that don't need them.<br>
<blockquote cite="mid:906DBAA1-30A8-4FC0-A2CE-89AFD8A584B1@mac.com"
 type="cite">
  <pre wrap="">-Doug

  </pre>
</blockquote>
--Ned.<br>
<pre class="moz-signature" cols="72">-- 
Ned Batchelder, <a class="moz-txt-link-freetext" href="http://nedbatchelder.com">http://nedbatchelder.com</a>
</pre>
</body>
</html>