We had a bug where it automatically switched you to the new build when you already had a selected build as soon as you captured a new story. The specified behaviour was that it should "hold" until you opt-in (by clicking the header) or change story.
This ensures that (and adds a story that tests the changing story part actually works)...
To QA:
Open a branch with a build, view a snapshot
Run another build, let it finish
Ensure you are still viewing the old snapshot (it should say "View latest snapshot" in the header, or check the build # in the footer).
Change story
Check you are now viewing the new build.
📦 Published PR as canary version: 0.0.110--canary.130.339125d.0
:sparkles: Test out this PR locally via:
```bash
npm install @chromaui/addon-visual-tests@0.0.110--canary.130.339125d.0
# or
yarn add @chromaui/addon-visual-tests@0.0.110--canary.130.339125d.0
```
For me it's less about the state management (the file that transitions is pretty simple really), and more about how to test it. Unit tests are better than nothing but don't really cut it here.
Telescoping from https://github.com/chromaui/addon-visual-tests/pull/124
We had a bug where it automatically switched you to the new build when you already had a selected build as soon as you captured a new story. The specified behaviour was that it should "hold" until you opt-in (by clicking the header) or change story.
This ensures that (and adds a story that tests the changing story part actually works)...
To QA:
Check you are now viewing the new build.
📦 Published PR as canary version:
0.0.110--canary.130.339125d.0
:sparkles: Test out this PR locally via: ```bash npm install @chromaui/addon-visual-tests@0.0.110--canary.130.339125d.0 # or yarn add @chromaui/addon-visual-tests@0.0.110--canary.130.339125d.0 ```