Closed Bug 683294 Opened 15 years ago Closed 14 years ago

Update assertion module for new deepEqual assertions

Categories

(Mozilla QA Graveyard :: Mozmill Tests, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: whimboo, Assigned: whimboo)

References

Details

(Whiteboard: [lib])

Attachments

(4 files)

On bug 671290 the deepEqual assertions have been added. We should port those to our own API and make it available for our current shared modules.
Assignee: nobody → hskupin
Status: NEW → ASSIGNED
Depends on: 696484
Blocks: 696724
This patch follows the changes in Mozmill and replaces the current equal/notEqual code with the deep equal checks.
Attachment #569201 - Flags: review?(gmealer)
Attachment #569201 - Attachment description: Patch v1 → Patch v1 (old modules)
Pointer to Github pull-request
Attachment #569204 - Attachment description: Pointer to Github pull request: https://github.com/geoelectric/mozmill-api-refactor/pull/9 → Patch v1 (api refactor)
Attachment #569204 - Flags: review?(gmealer)
Comment on attachment 569201 [details] [diff] [review] Patch v1 (old modules) [checked-in] > // THIS IS NOT TESTED NOR LIKELY TO WORK OUTSIDE V8! That's comforting. :/ > } else if (typeof actual != 'object' && typeof expected != 'object') { > return actual == expected; Not saying this is wrong, but not sure what behavior this produces. Strict identity was covered above, so I think what this'll do is essentially: if (actual === expected) { return true } else if neither is an object && (actual == expected) { return true } ...which is equivalent for most non-objects to just testing actual == expected. This isn't in line with our previous semantics, which are strict ===. // 7.4. For all other Object pairs, including Array objects, equivalence is ...which hands off to _objEquiv, which is documented as potentially expensive. Also, assuming keys give back properties, it'll hit those and it may cause side effects (though writing a get property with a side effect is a design bug itself). If it doesn't see properties, it won't properly verify value equality. So here's my take: The code's OK, as far as it goes. It's mostly c/p from a known-good project. I don't fully understand the behavior. I do know it won't be the same as the function it's replacing, which is a strict ===. Calling this may be expensive, and might cause side effects due to the key access issue. Right now, because of those issues, I think I'm in favor of keeping things the way they were and introducing deepEqual to be used only when a deep equal is needed. Once we've answered this review, I'll review the one for the API refactor project. We're going to want them to act the same.
BTW, r- based on comments, but it's really high-level discussion about whether to go this route and I have no problem based on the code. Not sure what that means so leaving it "unreviewed."
I would rather stay in sync with Mozmill code here. Otherwise we can run into issues when switching between 1.5.x and 2.0. Personally I also don't like that external code that much given the statements you already have made. I would kinda like to get this solved by Mozmill devs and file a follow-up bug for it.
I guess I thought the "old modules" patch was the Mozmill code, but maybe that was just the 1.5 compatibility library. So this change has already been made for 2.0? I agree we need to stay in sync, but I think there are some issues making this change at all.
This change has been checked-in for Mozmill 2.0 and on master. See bug 696484 where you are also CC'ed.
Comment on attachment 569201 [details] [diff] [review] Patch v1 (old modules) [checked-in] I don't agree with this checkin in general, but agree we need to stay in sync.
Attachment #569201 - Flags: review?(gmealer) → review+
Comment on attachment 569204 [details] Patch v1 (api refactor) [checked-in] Looks fine. I merged from Github already.
Attachment #569204 - Flags: review?(gmealer) → review+
So how should we proceed forward? I'm uncomfortable with this change. For that matter, I really don't understand why people think a group of simple assertion functions needs to be pared down this much. It's bike shed optimization at the cost of specificity. Yeah, they're a plethora of what amounts to renames. That's what makes the test code readable. The actual maintenance on them will be close to nil.
Blocks: 697381
(In reply to Geo Mealer [:geo] from comment #10) > So how should we proceed forward? I'm uncomfortable with this change. I have filed bug 697381 which we can use to clarify remaining issues. Landed as: http://hg.mozilla.org/qa/mozmill-tests/rev/13fbfcb6f832 (default) http://hg.mozilla.org/qa/mozmill-tests/rev/2d3e4f6de7a3 (aurora) http://hg.mozilla.org/qa/mozmill-tests/rev/4856d46f8448 (beta) http://hg.mozilla.org/qa/mozmill-tests/rev/a73cf599b7cd (release)
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
We want to revert this change given our discussion on bug 697381.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Attachment #569201 - Attachment description: Patch v1 (old modules) → Patch v1 (old modules) [checked-in]
Attachment #569204 - Attachment description: Patch v1 (api refactor) → Patch v1 (api refactor) [checked-in]
This patch reverts the combination of equal and deepEqual for the current modules.
Attachment #575468 - Flags: review?(gmealer)
Pointer to Github pull-request
Comment on attachment 575469 [details] Patch (revert - api refactor) Patch for the API refactor project.
Attachment #575469 - Attachment description: Pointer to Github pull request: https://github.com/geoelectric/mozmill-api-refactor/pull/10 → Patch (revert - api refactor)
Attachment #575469 - Flags: review?(gmealer)
Comment on attachment 575468 [details] [diff] [review] Patch (revert - current modules) Looks good. Appreciate the revert! r+
Attachment #575468 - Flags: review?(gmealer) → review+
Comment on attachment 575469 [details] Patch (revert - api refactor) Reviewed and merged on github, r+
Attachment #575469 - Flags: review?(gmealer) → review+
Component: Mozmill Shared Modules → Mozmill Tests
Whiteboard: [lib]
Product: Mozilla QA → Mozilla QA Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: