<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>