Skip to content

Modes#27

Open
jembezmamy wants to merge 2 commits intoCropster:masterfrom
nibynic:modes
Open

Modes#27
jembezmamy wants to merge 2 commits intoCropster:masterfrom
nibynic:modes

Conversation

@jembezmamy
Copy link
Contributor

I've got a project with responsive design which should be tested in different screen resolutions. I thought it could be useful to support multiple configurations, instead of just one resolution per whole application.

Here I've implemented something I called modes (I'm not sure if that's a good word...). Basically it does just that - allows you to define multiple configurations and then pick one in each capture call.

// ember-cli-build.js
let app = new EmberAddon(defaults, {
  visualTest: {
   // some configuration params ommited for brevity
   windowWidth: 1024,
   modes: {
     tablet: {
       windowWidth: 768
     },
     mobile: {
       windowWidth: 412
     }
   }
  }
});
// this will use default config
// and will create visual-test.png file:
await capture(assert, 'visual-test');

 // this will use mobile mode config
// and will create visual-test-mobile.png file:
await capture(assert, 'visual-test', { mode: 'mobile' });

@mydea
Copy link

mydea commented Nov 26, 2018

Thanks for the PR!
I really like the idea, not sure about the solution though.

Wouldn't it be nicer to allow specifying the screen dimensions directly as options for the capture helper? E.g.

await capture(assert, 'mobile-test', { windowWidth: 440, windowHeight: 680 });

And then just set the window size to these values, if present, in the _makeScreenshots() method? This would make this configurable directly in the test and make this less "magic".

@jembezmamy
Copy link
Contributor Author

Yeah, I thought about this solution, but I felt it will make a mess in tests code. I thought about two use cases:

  • multiple params per mode - one or two config params look ok, but it will become confusing if I use more (like deviceScaleFactor or mobile) and start repeating different configs again and again. Alternatively I could define my config in a constant and reuse it like this:
import { MOBILE } from 'tests/helpers/visual-test-setups';
await capture(assert, 'mobile-test', MOBILE);
  • multiple modes per test - it's not implemented yet, but with modes we could allow passing multiple mode names to one test - that would make it more clear.
await capture(assert, 'visual-test', { modes: ['mobile', 'tablet', 'default'] });

There is also a technical reason, why I used centrally defined configurations - I'm not sure if simple-headless-chrome allows you to change device settings once browser is initialized. I couldn't make it work, so now I create a separate browser instance per mode. 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants