-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: demo workspace e2e #3889
feat: demo workspace e2e #3889
Conversation
Removed vultr server and associated DNS entries |
add new scenarios to feature file revert ui-driven test changes update feature with new tests add step structure and helper
add Given logic and alter jwt build for demoUser lint fix refine Given statements add When steps add Then steps lint:fix tidy verification and helper
80e1e14
to
24242e2
Compare
refine race condition Promise.All improve error catching on createFlow
1b97644
to
1623a33
Compare
fix MyMutation naming
3da8ef4
to
ed9bf95
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Loved how you split the steps up into the different types - really clear to read through.
I've mainly added some wording/variable name change suggestions to make it even clearer!
e2e/tests/api-driven/src/demo-workspace/steps/navigation_steps.ts
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great! ✨
What does this PR do?
This PR follows on for demo workspace work here: https://trello.com/c/EfaEQRzK/2441-create-a-demo-workspace
I have written a suite of api-driven e2e tests to ensure
demoUser
restrictions and capabilities are maintained during future code changes.Strategy
To ensure a future dev could understand the tests and the nuances around database permissions, I have explicitly written out what data should be in the database during the tests in the
Given
statements within theBackground
of the.feature
file. With this, I am able to populate the db directly with thedatatable
information.To support the range of scenarios and different situations, I have split out the
.steps
file out intobackground | navigation | verification
with each file handling either theGiven
steps, theWhen
steps, or theThen | But
steps.This felt better from a readability point of view as putting them all in the same file became unwieldy and collating
When
orThen
conditions seem to abstract the point of some of the tests.The
helper.ts
file contains a lot of GraphQL requests because I had to return specific data or send specific data and found the shared requests didn't give me enough control on things likeid & creator_id
. This is similar for the types likeFlow
etc.Struggles
I did struggle a bit with the right design patterns here and thinking about what code should sit within which kind of step, what goes in a
When
compared with aThen
but I hope my use of state helps this.I seem to hit a randomly occurring error as well around the creation of flows, I couldn't pinpoint how it is happening or what is causing it. The addition or removal of a
console.error
seems to trigger the error sometimes, so I thought it may be a race condition around aPromise.all()
but I couldn't root it out... if anyone finds something, let me know, for now it is all passing.