-
Notifications
You must be signed in to change notification settings - Fork 245
chore(e2e): restructure e2e test helpers to better separate shared state and setup / teardown functions COMPASS-8361 #6383
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
Conversation
…ate and setup / teardown functions
|
|
||
| // should we test compass-web (true) or compass electron (false)? | ||
| export const TEST_COMPASS_WEB = process.argv.includes('--test-compass-web'); | ||
| export const TEST_COMPASS_WEB = _TEST_COMPASS_WEB; |
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.
I'll do a follow-up to change the exports for all re-exported vars, just didn't want to make this patch too noisy
|
|
||
| if (TEST_COMPASS_DESKTOP_PACKAGED_APP) { | ||
| debug('Building Compass before running the tests ...'); | ||
| await buildCompass(); |
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.
Some of these probably can be just moved here directly as they are just running scripts with crossSpawn, then it's maybe easier to read through the compass.ts file
| "debug": "^4.3.4", | ||
| "depcheck": "^1.4.1", | ||
| "electron": "^30.5.1", | ||
| "electron-to-chromium": "^1.5.41", |
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.
nice! Would be worried about what happens if we're ever ahead of them, but I suppose that's unlikely because I see this package is a dep of browserslist so should be safe enough.
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.
Yeah, that's a valid point, generally speaking you're right, we'd probably always stay on the same version without any extra effort from our side, but I'm also doing something similar in this other WIP PR, and will copy this part that makes sure that we update electron with browserslist in this one
| semverCondition: string, | ||
| enterpriseExact?: boolean | ||
| ) => { | ||
| const { version, enterprise } = DEFAULT_CONNECTIONS_SERVER_INFO[0]; |
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.
Probably not for this PR and I realise you found it this way, but should we continue to assume the connections are all running the same server version?
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.
Good question! Restructuring this code a bit just highlighted this assumption we're making that's technically is not very safe, but at the same time the second connection is almost always created just so we have multiple running at the same time and so the assumption we're making feels safe? We probably can make it all more explicit somehow, at least documenting it for the method as the easiest step 🙂
I think we can do a few things here if we wanted to, one thing that comes to mind right away is that serverSatisfies can take a connection name as an argument, so that we're explicit against what we're checking here. I am planning to do a follow-up specifically to align a bit the skipIf / satisfies interfaces, so might be a good point to do something like this.
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.
Yes it feels safe and indeed only became obvious because of the restructure. We indeed only have multiple connections since recently just for the sake of having two for the MC feature. Only thing I can think of is that someone one day might be running servers of multiple different versions at once, but then this will quickly become an obvious bug they will find.
Just thinking that we could start multiple servers of different versions then for the handful of cases where we do care about different results for different versions we could wrap the test in a for loop. Then we probably don't ever have to run the entire e2e test suite multiple times for different server versions in CI which could alleviate some of the limited mac resource problems..
Anyway. That's just me thinking out loud. I don't think we need to do anything right now. And there might be an opportunity here in future :)
| // eslint-disable-next-line @typescript-eslint/no-var-requires | ||
| const { ipcRenderer } = require('electron'); | ||
| ipcRenderer.invoke('compass:maximize'); | ||
| void ipcRenderer.invoke('compass:maximize'); |
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.
oops. that was me.
| ); | ||
| } | ||
|
|
||
| // TODO: Probably time to use some arg parser for this already |
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.
yeah...
|
|
||
| if (typeof electronPath !== 'string') { | ||
| throw new Error( | ||
| 'Running e2e tests in an unsupported runtime: `electron` is not a string' |
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.
you mean electronPath?
lerouxb
left a comment
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.
Really nice cleanup! Long overdue too.
…runner This also includes re-applying changes from #6381 from scratch
| const TEST_ATLAS_CLOUD_EXTERNAL_DEFAULT_CONNECTIONS: ConnectionInfo[] | null = | ||
| JSON.parse(process.env.TEST_ATLAS_CLOUD_DEFAULT_CONNECTIONS ?? 'null'); |
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.
@syn-zhu FYI, I'm changing this to be a stringified json array with connections following ConnectionInfo type schema because we're refactoring these STRING_1 / NAME_1 variables to be always derived from a list of connection info objects
| // To be able to use `setCookies` method, we need to first open any page on | ||
| // the same domain as the cookies we are going to set | ||
| // https://webdriver.io/docs/api/browser/setCookies/ | ||
| await browser.navigateTo(`${TEST_ATLAS_CLOUD_EXTERNAL_URL!}/404`); |
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.
@syn-zhu FYI, dropping the protocol from the url as this is a _URL, not just a domain
| await browser.setCookies( | ||
| cookies | ||
| .filter((cookie) => { | ||
| cookie.name.includes('mmsa-') || |
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.
Not sure how it worked before, without a return this would just filter out all the cookies from the array
This is a pre-requisite work I'm doing as part of adding e2e tests for logged in Atlas user in compass-web sandbox. We're starting to have a decent amount of branching logic in setup and teardown based on what exact type of e2e we are running: desktop packaged / just compiled, compass-web, compass-web with atlas login. Most of these will run exactly the same suites, but managing the initial setup logic starts to get a bit hairy, so this patch does some refactoring to try to address that: