Assertion match fails with data attribute

[eskimoblood]

When I use the match assertion to check for a data attribute the assertion fails:

 expect(meElement[0]).toMatch({id: 'id1', 'type':'checkbox', 'data-path':'foo.bar'}); 

while this assertion passes

expect(myElement.data('path')).toEqual('foo.bar');

[augustl]

Thanks! @cjohansen is the assertion guy, but afaik the assertion system has no special handling of DOM elements, it just checks if theElement[prop] is identical to expectedObj[prop]. And:

var el = document.createElement("div");
el.setAttribute("data-foo", "foo");
el.getAttribute("data-foo") // "foo"
el["data-foo"] // undefined

It makes sense to me that we have special handling of DOM elements, so that we can easily assert things like data-xxx props.

[cjohansen]

Meh, not so sure about this situation. We actually do handle DOM elements specially when there are two of them. But for this case, I would perhaps suggest a custom assertion. How can we solve this in a general matter in samsam/referee?

[augustl]

We could have a separate assertion for DOM element attributes.

assert.attributes(domNode, {"className": /\bmy-class\b/, "data-id": "520"})

But why not let assert.match be polymorphic, and trigger DOM node attribute match when actual is an element and expected is an object?

Alternatively, we can wrap elements and use assert.match(zing(element), {"data-foo": "foo"}). zing could turn the DOM element into a plain object.

[dwittner]

What do you think about this solution:

if (matcher && typeof matcher === "object") {
    var prop;
    for (prop in matcher) {
        var value = object[prop] || object.getAttribute ? object.getAttribute(prop) : undefined; 
        if (!match(value, matcher[prop])) {
            return false;
        }
    }
    return true;
}

[cjohansen]

I like it. It's a nice and pragmatic approach to the problem, making assert.match behave like expected. 👍

[dwittner]

Implemented by d6d507e925.