test: project create and delete react e2e [INFENG-456] #9244
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #9244 +/- ##
==========================================
- Coverage 51.22% 43.99% -7.23%
==========================================
Files 747 423 -324
Lines 110720 70801 -39919
Branches 2778 2779 +1
==========================================
- Hits 56718 31152 -25566
+ Misses 53827 39474 -14353
Partials 175 175
Flags with carried forward coverage won't be shown. Click here to find out more.
|
✅ Deploy Preview for determined-ui ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
| }); | ||
|
|
||
| static withName<T extends Card>( |
There was a problem hiding this comment.
cool! is this like a second constructor? could we use this syntax, or would that not be the same? just curious
export class CardWithName<T extends Card>
There was a problem hiding this comment.
Yeah, it's similar to a constructor. I think this factory pattern is the cleanest though. I'm open too ideas but I tried a couple options.
I did try making this a second constructor on Card but this doesn't work because it always returns a Card. I don't think new Card(name, type) can actually return a ProjectCard or WorkspaceCard. Maybe it could satisfy the interface based on class shape, but we'd always have to cast it to a more specific type when we work with it which is a pain. If there is clean way to do it I'd prefer this route, but I don't see a good way.
Likewise, I think a new CardWithName<ProjectCard>(name) would return a CardWithName<ProjectCard> class. We could then retrieve an instance of ProjectCard from it but then we are back to a factory pattern with more steps.
I can't make this a constructor on ProjectCard because then it doesn't encapsulate the selector logic so I'd have to re-define that logic for each card type.
There was a problem hiding this comment.
okay nice. thanks for checking all that! and i think this solution looks clean too. you're doing something pretty different from what i did with tables and rows too.
There was a problem hiding this comment.
I can't make this a constructor on ProjectCard because then it doesn't encapsulate the selector logic so I'd have to re-define that logic for each card type.
export class CardWithName<T extends Card> extends Card
looks a little ridiculous lol
| // test.afterEach(async ({ page }) => { | ||
| // const workspacesPage = new Workspaces(page); | ||
|
|
||
| // }); | ||
|
|
||
| // test('Projects and Workspaces archival and pinning', async ({ page }) => { | ||
| // await test.step('Archive a workspace', async () => {}); | ||
| // await test.step('Unarchive a workspace', async () => {}); | ||
| // await test.step('Unpin a workspace through the sidebar', async () => {}); | ||
| // await test.step('Pin a workspace through the sidebar', async () => {}); | ||
| // await test.step('Archive a project', async () => {}); | ||
| // await test.step('Unarchive a project', async () => {}); | ||
| // }) |
There was a problem hiding this comment.
Nice, guessing just something to add in later.
djanicekpach
force-pushed
the
djanicek/infeng-456/projects-create
branch
from
be081cd
to
2044210
Compare
djanicekpach
force-pushed
the
djanicek/infeng-456/projects-create
branch
from
30c43f9
to
99d1e2a
Compare
Ticket
INFENG-456
Description
This adds react E2E tests and page object models for project creation and deletion. This does not complete the the full test we are automating, but it is a self contained test with usable page objects so I'm going to merge it to prevent conflicts later.
Test Plan
CI passes OSS and EE
Checklist
docs/release-notes/.See Release Note for details.