We've added a toHaveClass
custom jasmine matcher and, in order to make it work, we had to add it to beforeEach()
(with the help of this topic).
And, to follow the DRY principle and to avoid repeating the matcher definition in every beforeEach()
in specs where toHaveClass
is needed, we've added a beforeEach()
block right into onPrepare()
:
onPrepare: function () {
var jasmineReporters = require("jasmine-reporters");
require("jasmine-expect");
// ...
// custom matchers
beforeEach(function() {
jasmine.addMatchers({
toHaveClass: function() {
return {
compare: function(actual, expected) {
return {
pass: actual.getAttribute("class").then(function(classes) {
return classes.split(" ").indexOf(expected) !== -1;
})
};
}
};
}
});
});
},
It actually works, but every time I see beforeEach()
block inside the protractor config, I have a micro-depression and a strong feeling it is not a good place to define matchers.
The Question:
Is there a better way or place to have custom matchers defined?
The most simple solution I see is to move this beforeEach
block to a separate file and require it inside onPrepare
, like you do with vendor libs:
onPrepare: function () {
var jasmineReporters = require("jasmine-reporters");
require("jasmine-expect");
require('./tests/support/jasmine-custom-matchers'); // inject custom matchers
// ....
}
The code of the beforeEach
should not require any changes:
// /tests/support/jasmine-custom-matchers.js
beforeEach(function() {
jasmine.addMatchers({
toHaveClass: function() {
return {
compare: function(actual, expected) {
return {
pass: actual.getAttribute("class").then(function(classes) {
return classes.split(" ").indexOf(expected) !== -1;
})
};
}
};
}
});
});
I do not think you should export
something from this file though, it will take effect by just require
-ing it.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With