-
Notifications
You must be signed in to change notification settings - Fork 364
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
test: Jcom/infeng 454/sign in tests #9013
Conversation
✅ Deploy Preview for determined-ui ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
54a0a8e
to
d1252b7
Compare
d1252b7
to
f0e6b67
Compare
@@ -87,6 +87,7 @@ const DeterminedAuth: React.FC<Props> = ({ canceler }: Props) => { | |||
|
|||
const loginForm = ( | |||
<Form | |||
data-test="authForm" |
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.
spelling: data-testid
I think you mean?
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.
actually, i like top level components to have data-test
. when the form gets implemented in SignIn.tsx
, sign in could give it a data-testid
, but it wouldn't need to unless it was instantiating more than one of this component. I'll write this up in a guide somewhere.
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.
Why do you like top level components to be slightly different? To me it reads like an extra style thing for maintainers to remember and no implied meaning.
If you do want the top level to be different, can it be explicit? Something like data-top-level-testid
or data-formid
? It'd be good if the name was different enough to indicate that this difference is intentional, and ideally it could also describe why it was different.
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.
maybe this?
data-test-component='my-component'
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.
Seems diffferent enough form data-testid to avoid confusion. works for me!
placeholder="password" | ||
prefix={<Icon name="lock" size="small" title="Password" />} | ||
/> | ||
</Form.Item> | ||
{isBadCredentials && ( | ||
<p className={[css.errorMessage, css.message].join(' ')}>Incorrect username or password.</p> | ||
<p className={[css.errorMessage, css.message].join(' ')} data-testid="error">Incorrect username or password.</p> |
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.
nitpick: maybe bad-cred-error
or something in case there is ever more than one on the page?
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.
there actually are two alerts since there's almost always one in the bottom right. I'd like to have a list of errors. Maybe a BaseComponents
plural class?
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.
A list of errors would be nice. Feel free to punt to out of scope and make a follow up ticke here though since it sounds like that might be more involved. I don't love plural classes in languages with generic types. We can just do a Array and get most of the functionality for a lot less code.
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.
actually, this isn't even the notification that shows in our test. im gonna delete this change
throw new Error('username must be defined') | ||
} | ||
if (typeof process.env.PW_PASSWORD === "undefined") { | ||
throw new Error('username must be defined') |
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.
copy&paste: password instead of username.
get locateSelf(): Locator { | ||
if (typeof this._locator === 'undefined') { | ||
this._locator = this._parent.pwLocatorFunction(this.#selector); | ||
Object.freeze(this._locator) |
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.
Why are we freezing the object here? It makes me a little nervous. Hopefully playwright doesn't keep any mutable data on Locator classes under the hood!
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 wanted the attribute to only be instantiated once. it's kind of like saying
const myLocator = page.locator('my_selector')
I didn't want to create the "const" until we started using it. it behaves like a readonly
that we're allowed to write to once.
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.
Object.freeze is a bit different than const or readonly. It prevents reassignment, but also prevents changing the properties of the underlying object. If playwright ever alters a property under the hood (it's their object so that's pretty reasonable) it could cause a crash.
I love having constants instead of variables, but for a protected variable with a public getter, I think the benefits of this lockdown are kind of minimal when compared to the potential consequences. If you really want to protect it you could make a setter and either declare it private, or throw an error when it gets set and already has a value.
export class SignIn extends BasePage { | ||
readonly pageComponent: PageComponent = new PageComponent({parent: this}); | ||
readonly detAuth: DeterminedAuth = new DeterminedAuth({parent: this.pageComponent}) | ||
// TODO add SSO page model as well |
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.
This seems probably out of scope, so feel free to make a ticket for sso. I think a lot more setup has to go into it.
get locateSelf(): Locator { | ||
if (typeof this._locator === 'undefined') { | ||
this._locator = this._parent.pwLocatorFunction(this.#selector); | ||
Object.freeze(this._locator) |
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.
Object.freeze is a bit different than const or readonly. It prevents reassignment, but also prevents changing the properties of the underlying object. If playwright ever alters a property under the hood (it's their object so that's pretty reasonable) it could cause a crash.
I love having constants instead of variables, but for a protected variable with a public getter, I think the benefits of this lockdown are kind of minimal when compared to the potential consequences. If you really want to protect it you could make a setter and either declare it private, or throw an error when it gets set and already has a value.
@@ -87,6 +87,7 @@ const DeterminedAuth: React.FC<Props> = ({ canceler }: Props) => { | |||
|
|||
const loginForm = ( | |||
<Form | |||
data-test="authForm" |
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.
Why do you like top level components to be slightly different? To me it reads like an extra style thing for maintainers to remember and no implied meaning.
If you do want the top level to be different, can it be explicit? Something like data-top-level-testid
or data-formid
? It'd be good if the name was different enough to indicate that this difference is intentional, and ideally it could also describe why it was different.
placeholder="password" | ||
prefix={<Icon name="lock" size="small" title="Password" />} | ||
/> | ||
</Form.Item> | ||
{isBadCredentials && ( | ||
<p className={[css.errorMessage, css.message].join(' ')}>Incorrect username or password.</p> | ||
<p className={[css.errorMessage, css.message].join(' ')} data-testid="error">Incorrect username or password.</p> |
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.
A list of errors would be nice. Feel free to punt to out of scope and make a follow up ticke here though since it sounds like that might be more involved. I don't love plural classes in languages with generic types. We can just do a Array and get most of the functionality for a lot less code.
@@ -17,7 +17,7 @@ export default defineConfig({ | |||
fullyParallel: !!process.env.CI, | |||
|
|||
/* https://playwright.dev/docs/test-timeouts#global-timeout */ | |||
globalTimeout: 3 * 60 * 1000, // 3 min | |||
globalTimeout: process.env.PWDEBUG ? 0 : 3 * 60 * 1000, // 3 min unless debugging |
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! I was thinking about doing this and forgot.
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #9013 +/- ##
==========================================
- Coverage 47.80% 41.63% -6.18%
==========================================
Files 1161 847 -314
Lines 143646 104428 -39218
Branches 2373 2377 +4
==========================================
- Hits 68673 43475 -25198
+ Misses 74820 60794 -14026
- Partials 153 159 +6
Flags with carried forward coverage won't be shown. Click here to find out more.
|
INFENG-454
Description
adds page models for sign in tests
add a new test for when we sign in with wrong creds
add test hooks into a few react components
Test Plan
the tests run on CI
Commentary (optional)
Checklist
docs/release-notes/
.See Release Note for details.
Ticket
INFENG-454