You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Difference is obviously testSpec.js has access to the device object core and can directly instantiate it (at least looks like from that testSpec.js), but of course it's read only to users.
So...this is easy, if someone wants to implement it, just export a property that can be set (e.g. stub or whatever name makes sense for this exported value)...that would allow people to set stubs. Then in the core devicejs code, it's probably already doing this in the new PR code? It would just check that property internally to see if it's been set, if so use the stub.window, else, continue on using the real window object. (so it'd just be stub.window || window at the top somewhere in the core code whereever it first starts to reference window essentially, and probably add some logic to handle if some properties aren't stubbed, etc.)
So I envision being able to do something like this in my test:
it('displays alternate subtitle and description for NFL non-game content', () => {
//...code here and then:
const window = {
navigator: {
userAgent: "Mozilla/5.0 (iPhone; CPU iPhone OS 6_0 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko)"
}
};
device.stub.window = window; // this is where we'd set the stub and devicejs would check that value internally to see if it's a literal or not. If so then devicejs internally would just use the stub instead of the real window object
console.log(device.mobile) // would return true!
//... rest of the test code etc.
});
This would be a very welcomed change. Right now I don't know what the last code is so I can't figure out where or how to contribute so if someone wanted to just add that exported value for us, that would be appreciated.
Essentially my test above was passing because the code checking agent was using the global.window (so I was able to stub it using navigator.__defineGetter__('userAgent', () => agent);). But we changed some of our code to use device.js instead. And now because of that I'm no longer able to still stub/fake the window, so now this test won't pass. So until we get a way to inject a stub like that for writing tests, I'm going to have to skip my test in our test suite for now.
The text was updated successfully, but these errors were encountered:
So I installed v0.0.3 and noticed someone added a
testSpec.js
(https://gist.github.com/dschinkel/293e86b3f65f7e4ddfd024980514ebcf) which had exactly what I'd like to do in my tests as a client of the lib.Difference is obviously
testSpec.js
has access to the device object core and can directly instantiate it (at least looks like from thattestSpec.js
), but of course it's read only to users.So...this is easy, if someone wants to implement it, just export a property that can be set (e.g. stub or whatever name makes sense for this exported value)...that would allow people to set stubs. Then in the core devicejs code, it's probably already doing this in the new PR code? It would just check that property internally to see if it's been set, if so use the
stub.window
, else, continue on using thereal window object
. (so it'd just bestub.window || window
at the top somewhere in the core code whereever it first starts to reference window essentially, and probably add some logic to handle if some properties aren't stubbed, etc.)So I envision being able to do something like this in my test:
This would be a very welcomed change. Right now I don't know what the last code is so I can't figure out where or how to contribute so if someone wanted to just add that exported value for us, that would be appreciated.
Essentially my test above was passing because the code checking agent was using the
global.window
(so I was able to stub it usingnavigator.__defineGetter__('userAgent', () => agent);
). But we changed some of our code to use device.js instead. And now because of that I'm no longer able to still stub/fake the window, so now this test won't pass. So until we get a way to inject a stub like that for writing tests, I'm going to have to skip my test in our test suite for now.The text was updated successfully, but these errors were encountered: