<div class="gmail_quote">On Sun, Jun 10, 2012 at 4:54 AM, Balazs Kelemen <span dir="ltr"><<a href="mailto:kbalazs@webkit.org" target="_blank">kbalazs@webkit.org</a>></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 class="im"><blockquote type="cite"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">So the unit tests are superfluous.  In particular, if I had to
          pick between only having unit tests or only having regression
          tests, I might pick unit tests.  But if I already have
          regression tests then I'm unlikely to want to incur technical
          debt to build unit tests, particularly since unit tests
          requiring changing the infrastructure to make the code more
          testable, which then leads to the problems listed above.<br>
        </blockquote>
        <div><br>
        </div>
        <div>There are many code paths are used rarely. In practice, we
          were having regressions frequently when people modified the
          code. Since the codebase has been unittested, the rate of
          regressions has gone down considerably. The time you spend
          dealing with tests is considerably less than the time you
          spend rolling patches in an out as you encounter different
          edge cases that different configurations/flags hit.</div></div></blockquote></div>
    A quick note to unittests. I think it's easy to define a hard limit
    for unittests, which is that: if I want to add a feature, or some
    customizing option for a particular port, it should be less effort
    to write the unittest than to write the actual code. I heard from my
    colleges a few times that it's not always the case with nrwt. I can
    imagine that it's not trivial to setup the unittest system for a
    module that has not been unittested so far but I think it should
    rather be the job of those who are actively working on the test
    harness, not of those who just need some work to be done for their
    port.</div></blockquote><div><br></div><div>My experience with code in general (and Python in particular) is that code that isn't tested is broken.  It's certainly true that several important parts of NRWT weren't designed with testing in mind, but that's something we should fix rather than piling on untested features.</div>

<div><br></div><div>That said, I'm not actively working on NRWT much these days, and I'm happy to defer to the folks who are as to what they think is best for the long-term health of this code.</div><div><br></div>

<div>Adam</div><div><br></div></div>