-
Notifications
You must be signed in to change notification settings - Fork 346
Improve readability for failing matchers -- toHaveAttr and more #184
Comments
I could not agree more @jesperronn. I think that some of the failing matcher messages are way to cryptic. It would be appreciated to see this improved. |
I was at the same issue until i stumbled upon the OP's thread. |
@inv-vinoth what is "the OP's thread"? Please provide a link or an explanation |
@jesperronn I was actually referring to your initial post.
Throws the below fail case.
It would be better if the error/fail messages is more friendly. |
@RLovelett @jesperronn Is there a reason that the PR associated with this issue (#187) has not been merged yet? I agree with @inv-vinoth that the failures are very hard to read and I made some modifications to the Here's the re-written toHaveClass: function () {
return {
compare: function (actual, className) {
var result = { pass: $(actual).hasClass(className) };
var wrapper = $(actual.clone()).wrap("div").empty().text("...").parent("div");
result.message = result.pass ?
"Expected " + wrapper.html() + " not to have class '" + className + "'." :
"Expected " + wrapper.html() + " to have class '" + className + "'.";
return result;
}
}
}, which produces the following kinds of messages:
Note that it strips out all of the nested nodes so that you are only left with the HTML for the node that should actually have the class. If I made similar changes to the other matchers and made a PR, would it actually be merged? |
hey peeps, check my comment here: #187 (comment). i'm definitely down for improving the output of the matchers, i'd just like them to be as consistent as possible so if we could update them all at once that'd be great. |
I'd also like to request this feature. I often find myself using
To this:
Only to change it back once I've tracked down the problem. It would save a lot of time to just see the actual value in the output. |
After updating to jasmine 2/jasmine-query 2.0.3 I found it hard to read the error messages.
Consider this example:
Given I have
result = $('<textarea name="field" maxchars="100"></textarea>)
expect(result).toHaveAttr('maxchars', '100'); //looks fine, sunshine scenario
expect(result).toHaveAttr('maxchars', '199); //fails
X should render a modal window contents
Expected { 0 : HTMLNode, length : 1, prevObject : { 0 : HTMLNode, length : 1 }, context : undefined, selector : 'textarea' } to have attr 'maxchars', '199'. (1)
I can debug much faster if I know that the actual field is found. And if I get an error message stating that the attribute is found, but has an incorrect value.
The outcomes of a failing scenario for toHaveAttr should probably cover:
Unfortunately, I am not attaching any pull request. Want to hear your thoughts for this.
/Jesper
The text was updated successfully, but these errors were encountered: