On 06/06/2014 10:29, James Graham wrote:
On 05/06/14 10:38, Mike de Boer wrote:

As I tried to explain, the CommonJS API naively made sense to me at
the time. To others as well, because we’re happily using it. As I now
understand, some of us are very attached to a specific, different,
API.

FWIW I don't think that I am attached to a "specific different api". I
am, however, attached to api semantics that make writing good tests
easy. I don't think that either CommonJS or SimpleTest achieve this in
their current form. For SimpltTest I think the main problems are:

* The is() and isnot methods use non-strict equality.

I will go ahead and assert that if you have a test that relies on strict versus non-strict equality, you should be using type checks to make that explicit, not an extra '=' in your comparisons. Makes assumptions much more explicit ("this return value should be a string '5' and not a number 5") rather than implied by the comparison function.

IOW, I wouldn't consider this a bug.

* ok() coerces its argument (this is a more minor problem).

I would even say s/more minor problem/feature/.

I've lost count of the number of times I've done:

ok(document.getElementById("foo"), "Foo should exist in the document")

and I'd hate to have to prepend !! to everything I wanted to check with ok().

* is and ok seem like pretty uninformative names. ise is even worse.

Agreed on 'ise', but I never use that (see above). I think 'is' and 'ok' are actually great names. They are short, the meaning is intuitively fairly obvious, and they "just work".

* The API is largely undocumented. From reading MDN you would think that
is, isnot and ok were the only methods. I can't find any other
doumentation except for the source.

This is fixable, of course. Much more easily so than swapping our assertion frameworks!


* All the todo stuff is mixing concerns. It forces you into a mode of
test writing where properties of a single implementation are hardcoded
into the testcases. This isn't a huge problem when there is only a
single relevant implementation, but we do a lot of work on standards
where there are multiple implementations.

And equally, we do a lot of work on e.g. browser mochitests. I would hate having to mess about to insert a todo() - these tests will only ever run against Firefox, and there's no point abstracting stuff.

* The fact that the implementation to todo* has to duplicate all the
comparison code is pretty terrible. Maybe that's why all the methods
other than ok, is, and isn are undocumented, because they don't have
todo equivalents.

This sounds like something we can fix in the code with one more level of indirection. :-)

~ Gijs

_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Reply via email to