Closed Bug 1025586 Opened 10 years ago Closed 10 years ago

MarionetteJS Tests for Smart Collections

Categories

(Firefox OS Graveyard :: Gaia::Everything.me, defect)

x86
macOS
defect
Not set
normal

Tracking

(b2g-v2.0 fixed, b2g-v2.1 fixed)

RESOLVED FIXED
2.0 S4 (20june)
Tracking Status
b2g-v2.0 --- fixed
b2g-v2.1 --- fixed

People

(Reporter: kgrandon, Assigned: kgrandon)

References

Details

(Whiteboard: [p=3],[systemsfe])

Attachments

(1 file)

(deleted), text/x-github-pull-request
kgrandon
: review+
daleharvey
: feedback+
amirn
: feedback+
Details
No description provided.
Attached file Github pull request (deleted) —
Comment on attachment 8440365 [details] Github pull request I'm pretty happy with this initial test. There's a lot more I'd like to start working on (custom collections), pinning, etc. I think integration tests can provide us a lot more value than unit testing (though there is good uses for both). Please let me know what you guys think of this initial test. Ran, Amir - I'd also like to spin you guys up on the framework so you can help write some of these tests. Take a look at the collection_test.js file - it's not too difficult, but it can take a while to learn how the testing framework works and such.
Attachment #8440365 - Flags: review?(ran)
Attachment #8440365 - Flags: review?(jlal)
Attachment #8440365 - Flags: review?(amirn)
Comment on attachment 8440365 [details] Github pull request I'm not really comfortable reviewing this since I am not familiar with the testing framework. As for the E.me changes, if I understand correctly we need a way to override the api URL for testing, but I don't think it should be part of gaia settings since it is a "device feature" and is not customizable. Can we find some other way to do this? We can refactor the `api.js` constructor to receive the URL if needed.
(In reply to Amir Nissim (Everything.me) from comment #3) > Comment on attachment 8440365 [details] > Github pull request > > since it **NOT** is a "device feature" and is not customizable.
I am fairly sure this needs to be a setting - it's the only way we can really test it from an integration test. Wherever you want to read the setting from in eme code doesn't really matter to me, sticking it in device.js made sense to me because we're already doing a get all of settings, so putting it there is going to not really slow down startup speed. (A new settingsLock may do that). My recommendation might be to just rename device.js to config.js or similar.
In that case I would prefer having a general `eme.device.env` setting to indicate we are running in test mode. Something like this maybe: https://github.com/EverythingMe/gaia/commit/8e483ede0517e4be1fa0e7dcd9d58ac8bf2237af Maybe there is already a setting that flags testing mode?
(In reply to Amir Nissim (Everything.me) from comment #6) > Maybe there is already a setting that flags testing mode? But we actually want to test our production code paths :) This also need to comes from settings somewhere, as we have to set it before the code runs. I'm fine with however you guys want to structure it as long as we get a nice settings hook to set the URL, and we don't impact startup time too much. I still think renaming device.js to config.js is the best approach, but whatever you guys want to do I'm fine with.
Kevin, please consider using this patch: https://github.com/EverythingMe/gaia/commit/e37453c3df2152fd637aa60d12725541fdeeced3 It creates `eme.config` with an apiUrl attribute. I moved the `readSettings` logic up to main `eme` object and then pass it to `eme.device.init`. So, we still have only one settings lock, eme.devic contains only device information and eme.config can be overridden by settings. Let me know what you think.
Flags: needinfo?(kgrandon)
Amir - sure, I think that could totally work for me! Let's get that landed and I'll rebase. Thanks!
Flags: needinfo?(kgrandon)
Amir - I applied the patch, and it seems to be working well. Thanks!
Comment on attachment 8440365 [details] Github pull request Dale - Maybe you will want to take a look at this because we might be able to use it or something similar for search app tests.
Attachment #8440365 - Flags: review?(dale)
Comment on attachment 8440365 [details] Github pull request These look great, I think James should have final review being more familiar with the marionette code, but in general its looking great. I do think it should likely go in shared, will definitely be reusing this
Attachment #8440365 - Flags: review?(dale) → feedback+
Attachment #8440365 - Flags: review?(amirn) → feedback+
Attachment #8440365 - Flags: review?(ran)
Attachment #8440365 - Flags: review?(jlal)
Attachment #8440365 - Flags: review+
Received a verbal R+ from James as he was sitting next to me.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Comment on attachment 8440365 [details] Github pull request This is needed for the vertical homescreen. We've done our best effort at testing this and believe it is safe for uplift.
Attachment #8440365 - Flags: approval-gaia-v2.0?(bbajaj)
Attachment #8440365 - Flags: approval-gaia-v2.0?(bbajaj) → approval-gaia-v2.0+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: