This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-01-19
Channels
- # announcements (1)
- # architecture (24)
- # beginners (7)
- # boot (7)
- # cider (1)
- # cljdoc (4)
- # clojure (20)
- # clojure-austin (1)
- # clojure-brasil (2)
- # clojure-dev (1)
- # clojure-italy (1)
- # clojure-spec (36)
- # clojure-uk (11)
- # clojurescript (44)
- # data-science (3)
- # datascript (1)
- # datomic (8)
- # figwheel-main (2)
- # fulcro (29)
- # graphql (9)
- # kaocha (2)
- # keyboards (1)
- # leiningen (3)
- # lumo (5)
- # nrepl (4)
- # off-topic (39)
- # onyx (5)
- # re-frame (2)
- # shadow-cljs (42)
- # tools-deps (18)
- # yada (65)
I've got an ongoing big problem that I have to work around, and big surprise, it's related to state---
I write a lot of end-to-end tests: I dig around in the DOM of our application, discovering things I want to grab to click or fill in or select, etc, and adding test-hooks to the code that generates the markup.
So I write code that drives what the state of our application is, and I read to it and write to it as though I were a human user
The most common mistake I make is thinking I'm in one application state when I'm not. So for instance, I have to open up an accordion to get at a button that will open a modal that I want to interact with, and I am not waiting long enough for the accordion animation
I do have predicates I can call to find out things about the current application state
but I thought I'd ask the #architecture crew if you think there's a strategy I should have in mind for this situation where I have state that I can't remove, cause I'm driving another program around into various states
my first half-baked solution is maybe I should create a model of the states and transitions available in the application, something viewable with graphviz, and use that to think with
@mathpunk to me it sounds that the problem is that your e2e tests derive the application state
optionally, you can have a separate component, that tries to get the application into the desired state
then you can optionally have a completely separate utility that tries to get the application into desired state X
i would probably prefer to rebuild application state from scratch in a fixture, if that's possible
but the methods they have for setting state is that "complex and error prone" bit you're talking about
have you looked at perhaps using something like https://github.com/reifyhealth/specmonstah ?