Fork me on GitHub
#architecture
<
2019-01-19
>
mathpunk17:01:43

I've got an ongoing big problem that I have to work around, and big surprise, it's related to state---

mathpunk17:01:56

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.

mathpunk17:01:22

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

mathpunk17:01:49

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

mathpunk17:01:51

that kind of thing

mathpunk17:01:38

I do have predicates I can call to find out things about the current application state

mathpunk17:01:39

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

mathpunk17:01:10

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

lmergen18:01:29

@mathpunk to me it sounds that the problem is that your e2e tests derive the application state

lmergen18:01:43

it seems a bit upside down

lmergen18:01:59

what i would personally do is take a bit of a "declarative" approach

lmergen18:01:21

e2e tests require a certain application state as a predicate

lmergen18:01:27

then they perform their test

lmergen18:01:47

optionally, you can have a separate component, that tries to get the application into the desired state

lmergen18:01:58

but this is completely separate from the actual test

lmergen18:01:05

the actual test should be just contracts

lmergen18:01:23

"provided state is X, if we do Y, then new state becomes Z"

lmergen18:01:07

then you can optionally have a completely separate utility that tries to get the application into desired state X

lmergen18:01:27

but this is fairly complex and error-prone

lmergen18:01:49

i would probably prefer to rebuild application state from scratch in a fixture, if that's possible

mathpunk20:01:45

i do have separation of the tests from the components that command state

mathpunk20:01:33

but the methods they have for setting state is that "complex and error prone" bit you're talking about

mathpunk20:01:11

thank you for your thoughts

lmergen21:01:10

have you looked at perhaps using something like https://github.com/reifyhealth/specmonstah ?