Skip to content
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

e2e test rework #173

Merged
merged 18 commits into from
Feb 16, 2024
Merged

e2e test rework #173

merged 18 commits into from
Feb 16, 2024

Conversation

dawhitla
Copy link
Contributor

Issue #, if available:

Description of changes:

Looking to improve the utility of our e2e tests and making it easier to write tests.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

@dawhitla dawhitla requested a review from cdg-me February 14, 2024 14:12
Copy link
Contributor

@cdg-me cdg-me left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like a great step forward 👍
Some future looking comments, but nothing that can't happen in a subsequent phase.

Once CI is passing, LGTM

afterAll(afterAllTestPlan);

it('paused controls playback state', async () => {
await waitForTestPlan(`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In a future pass, maybe something like a fluent DSL would be useful here. We could likely achieve similar readability, without the need to parse. Would also make it simpler to extend for more nuanced cases.

- onPlayerStateChange
`);
await waitForTap(by.id('paused'));
await waitForLogLabel('onPlayerStateChange ::: Playing');
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In a similar way, a DSL around validating outputs could also be useful. I think having separate test setup, execution and validation snippets can be useful, which I think it where this is going.

Ideally we're not verifying directly via logs, but collected output with post-execution validation (along with a more defined interface for the collected output) could work well.

@dawhitla dawhitla merged commit 61df02f into main Feb 16, 2024
5 checks passed
@dawhitla dawhitla mentioned this pull request Feb 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants