testing staged changes

[AdrienLemaire]

I've discovered BackstopJS recently and am trying to implement it in a project with a very high ratio of dynamic content (random feeds & co).

I would like to use BackstopJS in 2 steps:

• When a developer changes a file, I could detect the modified files a-la lint-staged and run backstopjs against these files in a husky pre-push hook.
• A travis CI instance connected to the github repo would run backstopJs against all pages of the application.

Can we handle the staged testing part without using the backstop.json file (which would be used on the ci) ? I'm currently thinking of adding documentation in each component file with metas for the scenarios, eg

/*
 * backstop-label: Contact page
 * backstop-url: /contact/
 * backstop-selectors: ["#contact"]
 */
import React, {Component} from "react";

export default class Contact extends Component {
  …
}

Then I'd be able to generate the label/url/referenceUrl/selectors objects for scenarios and rewrite the backstop.json file to test staged files.

I'm hoping that you have a better suggestion to handle this use-case to avoid the inline documentation overhead.

[garris]

Sorry -- not quite sure I understand what you're trying to test. Configs can be json or JS files that are executed at runtime. Configs can also be dynamically generated when running backstop as a module https://github.com/garris/BackstopJS/blob/master/README.md#integration-options-local-install

Hope that helps.

[AdrienLemaire]

As a developer, if I modify a component related to the contact page, I only want to have backstop test that page, not the whole application. Only the CI should be running the full css regression test suite.

I will try to write a js script by importing backstop and giving it an object built. thanks for pointing to the right documentation :+1:

[garris]

Ah, good. actually, you probably don't even need to use an active script. Just include the --filter=<scenarioForComponentName> argument when invoking backstop. Way easier.

[AdrienLemaire]

Got it, thanks. Closing since this looks resolved, and will reopen if I don't manage to implement it correctly :)

[garris]

Also, CSS is global scope -- so if your touching css you probably do want to test everything else -- at least at commit time. Food for thought there.

[AdrienLemaire]

We use cssInJs, and although we do have global css, we're trying to regulate it through material-ui themes. We also don't want to wait minutes before we can git push something, and pull requests cannot be merged until the CI check has passed, so it's fine in our case. Thanks for the heads up !