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?
1 Answers
Answers 1
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.
0 comments:
Post a Comment