On Thursday, 16 August 2012 18:21:35 UTC+2, Ehsan Akhgari wrote: > On the testharness.js side, we have things like assert_regexp_match, for > > example. I would argue that whether or not assert_regexp_match(a, > > /foo/, "msg") is more readable than ok(/foo/.match(a), "msg") is very > > subjective and depends on what the author of the test is used to see.
As the original author of testharness.js this is one style choice I feel I can defend. The API is indeed relatively large – but no more so than the typical JUnit inspired framework – but this design has substantial benefits, and it is easy to ignore the parts that you aren't using. The typical test format we used at Opera before testharness.js was exceedingly lightweight/liberal; it basically has a single function that takes a boolean indicating whether the test passed. Sadly this makes the tests very inconsistent and hard to read because every one is a special snowflake that does its own validation logic. This requires lots of code, often duplicated across tests, that is not really related to the thing under test but is needed to validate the results. It also means that every author makes their own decisions about how to do various kinds of test e.g. checking the right exception was thrown by a DOM method. The advantage of having a richer API is that it brings rigor and consistency to tests. By far the most common assertion in testharness.js is assert_equals. Even this simple method is a win compared to having people write their own equality test because it will always use strict equality. For more complex cases where the logic needed to make the test correct is more involved the benefits are correspondingly greater e.g. assert_array_equals removes the need for an explicit loop cluttering up the test itself and assert_throws has some relatively complex logic to handle checking the expected properties of DOM and ECMAScript exceptions. If test authors were left to reimplement on an ad-hoc basis the assertions that testharness.js provides built-in tests would be harder to read, less consistent, and more prone to error. That seems well worth the cost of a having such a rich API. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
