-
Notifications
You must be signed in to change notification settings - Fork 96
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: add BasePage testing util #343
Conversation
Adding BasePage for automation tests. |
I added BasePage for automation tests. |
decbbc3
to
f956459
Compare
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.
as far as i can see here -
this BasePage is a kind of util you plan to be used for a tests at this project,
am i right?
Hi, thanks for your contribution! |
Yes, indeed this is the aim of BasePage |
Thanks, I'll try a lit bit later to fix it. |
@DanLeshinsky i will be glad to talk with you on a our discord channel may be i can be useful here |
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.
Despite POM is listed as official Playwright tutorial, I believe it may become an antipattern when dealing with small projects such as this one. I'm afraid it will scare newcomers, and I'd like to make it simple-stupid as possible to let this project grow.
Nevertheless, if it will make some of our tests cleaner, we definitely should consider that. therefore I believe it would be fair to ask for some kind of POC that demonstrate how it will makes at least one of our tests more maintainable before merging it into our main development branch. WDYT?
Of course!!! It would be great to demonstrate it! Which way can I do it? Video/Zoom is good one? |
Code demonstration, by creating tests that will actually use this functionality. |
can you post a link to tutorial pls? |
This one: |
To be honest, I already wrote tests that use BasePage for timeline, but separated it into two PRs. Do you want me to create the second PR to take a look or combine all the files into one PR? Locally it's running correct using the POM. |
@DanLeshinsky feel free to submit this other branch. consider using |
test: add Timeline tests
} | ||
|
||
public async closeLineNumber() { | ||
await this.clickOnElement(this.close_line_number) |
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.
don't you agree that
await this.clickOnElement(this.close_line_number) | |
await this.close_line_number.click() |
will be simpler?
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.
additionally, using page.locator("span[aria-label='close']").click()
let the user immediately see and understand which selector is used. using this.close_line_number
is better in terms of reusability, but since we don't reuse this thing in many places, I think it's a little הכנה למזגן at this stage
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 can't agree with that because inside this.clickOnElement it's wrapped with test.step that can help with debugging, let's leave it as it.
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.
additionally, using
page.locator("span[aria-label='close']").click()
let the user immediately see and understand which selector is used. usingthis.close_line_number
is better in terms of reusability, but since we don't reuse this thing in many places, I think it's a little הכנה למזגן at this stage
This is the difference between somebody who is not working as an Automation developer but knows all different aspects of it and even can write automation by itself. I'll explain why I tell this )) Writing tests it's like writing a story. If you want to learn the system, learn it from automation tests. And when somebody new look on your test he should understand on the spot what this locator means (because it takes second to press ctrl + mouth click). When you fix your own test, you should know immediately what this locator means, but not start searching the css or xpath or whatever in browser. And as well your code is more organized like this. All locators in the same place, all functions and getters in other.
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 don't understand your comment.
I don't "knows all different aspects of it", and so do you.
I prefer simple solutions rather than smart ones.
We removed Yarn recently, not because it wasn't the right solution for the project. We did it because it's the right solution for us.
We have many junior contributors, and I don't find the complexity justified in this case.
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.
As you see in the ticket #296 I've planned dozens of tests to be done on this page, and I hope the functionality allowing to plan more additional tests. I hope the solution of POM is not the to smart ones, but the needed one. But of course I will be more than happy if junior contributors will learn to understand the difference between the main idea of using it or not.
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.
Let's give it a shot, maybe we'll all learn something :)
Description
this pull request suggests using POM to make our test suite more structured, by adding a BasePage for common actions among all automation tests.
close #297