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.
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.
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.
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
