On 04 Jun 2014, at 19:20, Ehsan Akhgari <ehsan.akhg...@gmail.com> wrote:
> On 2014-06-04, 5:45 AM, Mike de Boer wrote: >> On 04 Jun 2014, at 00:33, James Graham <ja...@hoppipolla.co.uk> wrote: >> >>> On 03/06/14 20:34, Boris Zbarsky wrote: >>> >>>> I'm arguing against Assert.jsm using the commonjs API names. >>> >>> And I am arguing against using the CommonJS semantics. If we are adding >>> new assertions it shouldn't be ones that encourage broken tests. >> >> I think this is very subjective and, to be honest, the first time I heard >> someone say that the CommonJS semantics are broken, even encourage broken >> tests. >> The API surface is concise enough to limit the amount of typing and convey >> the meaning of the method used. They achieved this to closely follow the >> English verbs of operators used to test an code block. I really don’t see >> how much closer you’d like to get to 'doing what you say you’re going to do' >> as far as API semantics go. >> I realise that this reasoning is subjective too. >> Furthermore, are the tests we have currently broken? Is there something we >> need to get increasingly worried about? > > Define broken. We do have quirks in each of our test frameworks that we'd do > differently if we went back in time and wanted to redo things again. I wasn’t implying that they’re broken at all, it’s just that James was hinting at that. > >> The reason CommonJS came into view was not because of it’s semantic >> superiority, but because of its similarity to both the XPCShell-test and >> Mochitest assertion styles and implementation. >> This way I thought we could circumvent ppl to get worried about re-inventing >> the wheel or something like that and view this change as an incremental step >> to gradually improve the blueprint overlap between the test suites in use. >> The benefit, IMHO, of incidentally using an assertion API that is widely >> used by the Javascript community, globally, was a nice side-effect. > > Well, honestly it seems like we're approaching the problem backwards, by > picking CommonJS first, and then figuring out what the implications are. I > think the right way to approach this is the exact opposite: first define what > the problems that we're trying to solve are, then figure out what the > technical options on solving those are, whether they require *any* changes to > the test APIs, and if so try to justify the changes very well, get feedback > on the proposed goals and changes to satisfy them, rinse and repeat. > I agree and I think that’s how things happened and the way I explained it above. As with anything that happens in the tree, they can be reversed if they appear to have been erroneous; back out. If you think that is the correct thing to do at this point, please file a bug to make this happen. > The other thing that you need to note is that there is years of experience > behind each one of our test frameworks, and there are probably several > hundred thousand lines of code written against any of them. And there are > many many people who have been using these frameworks for years now. > Completely replacing the testing API is pretty much as major a change as one > could possibly imagine. This is not a gradual change in any way. > It could be that we have a different understanding of the topic at hand, but we are talking about assertion methods, right? They’re the simplest of wrappers around comparing ‘a' to ‘b’ with `==` or `===`. I fail to see how consolidating these methods in a standalone module is at all about throwing away years of experience. Please understand that I did NOT replace the testing API, it is still there. The changesets of the bug that cover this work are minimal and intentionally so. Everyone can continue writing XPCShell tests the way they were used to. All the existing tests work like they did before. The assertion methods are still there and I don’t think they will _ever_ be removed. I’m not even saying they should be removed. Again, the implementation of the assertions themselves are still the same as before, they just live someplace else. Call it CommonJS, call it UnCommonJS, call it anything you want; things. did. not. change. I blame this misunderstanding on my apparent inability to explain things well enough from the get-go. My apologies. Mike. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
