Default Workflow seems like a bit of a hand grenade for juniors

[MalucoMarinero]

preface: I had a little look into the history of the default workflow after writing this issue and why it came about through the issues, so I sort of understand if there's reluctance to go back to screenshot commit and diff testing rather than this git workflow, possibly what I want isn't right for the project (in which case I might tend towards a fork). Close this if you think it's not applicable, but I need to get it off my mind as it's my main roadblock in bringing huxley as a core piece of my front-end workflow right now. The search for a good screenshot regression testing workflow continues I guess.

---

Hey there, this might seem a bit critical but it's only because huxley is, for me, so close yet just a little too cumbersome for use in a design heavy project where I'd like to screenshot every design component, possibly with a number of permutations.

The main problem for me is the default workflow, which is enough of a hand grenade for juniors that if it messes up their repository state, they can get confused about the correct steps to recover their work. I really believe the only tools that should mess with git should be version control tools, which this isn't, and I shouldn't have juniors thinking twice about running huxley because their repo wasn't in the right state. IMO the default should instead be something completely non-destructive, I'd think the best default would be a simple fill in the gaps approach where:

if there are tests without a recorded set of actions or screenshots missing, the CLI lists them out and then asks if you'd like to fill them out:

$ hux project/Huxleyfile.json

The following tests are missing recordings or screenshots:
InputLockup
SearchPanel
WidgetList

Do you wish to record and write screenshots for them now [Y/n]

...and if the recordings and screenshots ARE in place, runs through the lot with a less verbose output, grouped by Huxleyfiles, ie:

$ hux project/Huxleyfile.json

./project/Huxleyfile.json
  InputLockup  1 ✔  2 ✔
  SearchPanel  1 ✔  2 ✔  3 ✔ 
  WidgetList  1 ❌  diff at project/Huxleyfile/WidgetList.hux/firefox-1-diff.png

The only other thing I'd potentially want here would be an 'update' mode, where you can run through the entire set of tests, and if the test fails, have a chance to look at the result and see whether you want to replace the existing screenshots or not.

[chenglou]

You know what, this is a good point. I myself don't like the default workflow this much. We should change it.

Currently the repo's still maintained but I got annoyed enough by selenium that I'm just leaving this here, lol. Once I get the time (and if you deem this important enough), I should restart working on this actively.

[jhnns]

@chenglou I understand that... it feels like the tools aren't ready yet. Just wanted to say, that I'm still watching this repo (and hoping for progress) :grinning:

[MalucoMarinero]

Hey @chenglou, if you feel this is a reasonable mode to work on, I'm happy to have a crack in a fork and then send up a pull request. I'll set it up so it's a mode option, ie hux --shot-capture, hux --shot-update, then you the ball can be in your court regarding when, how, if you want to bring it in.

[chenglou]

@MalucoMarinero do you happen to use babel? I was wondering whether I should convert the codebase to use it. If not, feel free to work on the existing codebase. If so I should upgrade it first so that it doesn't look too messy.

[MalucoMarinero]

Yeah, I use babel, but I can get by in es5 or 6, makes no never mind to me.

[chenglou]

Alright then, go ahead =).

If you feel like it, remove the default workflow too! That was an interesting experiment to say the least.