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

Calls test runner directly from host process #62

Merged
merged 19 commits into from
Aug 12, 2024

Conversation

ChrisC
Copy link
Contributor

@ChrisC ChrisC commented Jul 25, 2024

As part of an effort to remove the IPC abstractions in favor of a single-process architecture in the harness, this draft PR calls the test runner functions directly from the main process without kicking off an "agent" child process.

As far as naming goes, I opted to keep the overall file and folder naming and organization conventions in place, and simply renamed files and folders formerly known as agent* to runner*.

Review Recommendation: There were quite a lot of files touched and/or removed in this PR, so I would recommend starting with a close look at the changes that happened in the host/main file to get an overall sense of how removing the agent process minimally affects the overall control flow for the harness.

TODO

  • Fix/update broken snapshot unit tests and types
  • Remove deprecated agent process files

@ChrisC
Copy link
Contributor Author

ChrisC commented Jul 25, 2024

@jugglinmike @gnarf this isn't quite ready to be reviewed yet but I would appreciate if either of you could pull this branch down and test if you can run it on NVDA? I've only tested this with Voiceover so far.

@jugglinmike
Copy link
Contributor

Hey @ChrisC; I'm working on testing this in Windows, but I'm having trouble getting it up and running locally (the harness is reporting an error connecting to at-driver). I'll give it another shot tomorrow.

@jugglinmike
Copy link
Contributor

(I should add that my problems can't be related to anything in this patch because I'm starting with the main branch as a base-line.)

@jugglinmike
Copy link
Contributor

Good news: as of commit b04b4b8, this branch produces equivalent output in Windows. Keep it up!

@ChrisC ChrisC marked this pull request as ready for review August 1, 2024 15:50
Copy link
Contributor

@gnarf gnarf left a comment

Choose a reason for hiding this comment

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

Still really think we need to track down and fix whatever caused you to be missing the : on URL.protocol

src/runner/driver-test-runner.js Outdated Show resolved Hide resolved
Copy link
Contributor

@jugglinmike jugglinmike left a comment

Choose a reason for hiding this comment

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

I tested this change with the Alert test plan on VoiceOver, and it produced equivalent results to the main branch. Nice work--this is a great simplification!

src/host/README.md Outdated Show resolved Hide resolved
src/host/main.js Outdated
await agent.start({ referenceBaseUrl: serverDirectory.baseUrl });
const timesOption = getTimesOption(options);

const emitter = new EventEmitter();
Copy link
Contributor

Choose a reason for hiding this comment

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

An event emitter seems like more than we need since we're only looking to resolve a single promise at the first occurrence of a single event. Think we can get away with leaking abortSignal's resolver function and invoking it directly?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Let me know if my latest commits address this! I was able to remove the emitter and just trigger via a promise resolver.

src/runner/messages.js Show resolved Hide resolved
* @returns {AriaATCIRunner.MockOptions}
*/
export function runnerMockOptions({ mock, mockOpenPage }) {
if (mock === undefined && mockOpenPage) {
Copy link
Contributor

Choose a reason for hiding this comment

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

In order to support this branch, the type for mock should read something like @param {boolean} [options.mock], and the same goes for the optional mockOpenPage parameter. That said, I'm wondering if we need to implement these branches in the first place. I personally tend to prefer explicitness over brevity, and in this case, the shorthand doesn't seem to be in use--the types used in the call site indicate that these values are always specified.

Copy link
Contributor Author

@ChrisC ChrisC Aug 8, 2024

Choose a reason for hiding this comment

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

Take a look at 75b5aa1. We weren't using the mock "config" in any meaningful way, and on closer look it struck as a classic case of YAGNI. I think we can get away with just a boolean CLI arg to determine whether or not to run the mock server.

@ChrisC ChrisC requested a review from jugglinmike August 8, 2024 23:54
Copy link
Contributor

@jugglinmike jugglinmike left a comment

Choose a reason for hiding this comment

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

Wondrous! Way to go, @ChrisC!

@jugglinmike jugglinmike merged commit 952bd8d into w3c:main Aug 12, 2024
4 checks passed
@jugglinmike jugglinmike deleted the remove-agent branch August 12, 2024 19:39
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.

3 participants