nickbeaird / pom-elements Goto Github PK

The goal of this project is to make it easier to import common functionality from the Selenium WebDriver or WebElement class methods, while also respecting that this project relies on composition rather than inheritance.

After thinking about the pom-elements package for a while, I am seeing that this project is attempting to organize Selenium into the framework that we communicate browser navigation with one another in a more natural sense. For example, while often pairing with an engineer, friend, or my parter and discussing a web page, the language revolves around "open your browser to this page" (Webdriver or PageObject) and then "click an element on the Page" (Page Element...or according to Martin Fowler a method). This issue attempts to align our day-2-day communication with our web testing with our testing framework.

That said, we now have to deal with the problem of bringing through a good handful of methods from underlying driver classes to our Page Object and the Page Element, but limiting access to other functions to keep our public API clean. There are many functions to bring through on both ends, and many functions to leave out of the mix. Thus, this leaves me thinking that this should not rely on inheritance of the driver instance and look more to composition. Once composition start repeating itself so many times, we are now stuck either writing a LOT of boilerplate. super. calls to the parent class, or using something like the Delegator Pattern. However, this issue is not being inclued in the MVP yet, as I will lean on boilerplate for the MVP if that helps communicate the project goals rather than getting too caught up in pre-mature optimization.

Here is an article that I have in mind for discussing how to move forward with the Delegator pattern.
https://www.michaelcho.me/article/method-delegation-in-python

The goal of this issue is to decrease the amount of time to run all of the tests while maintaining the breadth of the test quality.

A lot of the tests written for this project were done in A TDD approach. This helped me scaffold my thinking and features, but also capped my ability to keep the tests "clean". I was setting up a webdriver instance for every method, as I used the easy out-of-the-box pytest selenium webdriver instance. However, 40 test functions later means a lot of setup and tear down.

In the future we need to look at supporting all types of web driver implementations, but for now this aims to make it easier to make a change.

Supported/Tested:

• ✅ Selenium
• ✅ pytest (Chrome, Firefox, Safari)
• ✅ unittest (Chrome
• ✖️ selenium grid

The goal of this issue is to make sure that we decrease the number of dependencies for this project, so that the download size is small for others. I had not been as intentional with separating the development dependencies using the Poetry add --dev-dependency. This means that when I package up this project, it will have a great deal of dependencies that are mostly maintained for testing that the package works.

The documentation is autogenerated by pdoc from the docstrings (see pdoc). The type hinting for the mypy library is not showing and/or showing a virtual env path as selenium does not have publicly available type hints.

The goal is to get the methods that would communicate best the separation between how Page's and Elements are designed to function. This issue relates to GH-4.

User Stories:

• As a user, I want to know what functionality I should expect from my Page object, so that I know when and how to interact with the browser.
• As a user, I want to know what functionality I should expect from my Elements objects, so that I know when I can interact with an Elements.

Acceptance Criteria:

• All Classes and methods show up clearly in pdoc docs.
• Users can use any webdriver instance defined outside of pom-elements in addition to using PageObjects, Elements
• The methods for finding and interacting with items on the page (i.e. HTML Nodes, Webelements, text, Elemements) are all associated with the Elements classes.
• A Page class will have the methods that highlight when a web page should be interacted with.

I would like to have a base coverage report for this tool. This is a testing tool, and will likely hit scrutiny if it does not have one. A lot of this is being driven by a desire to know where I am missing on my TDD approach. Also, there are a lot of public projects that state that they have 100% test coverage. I want to show that off as well.

After running the coverage report, I am seeing that a single method is missing a test for an exception block. I wan that check mark.....

The methods on a page object are missing access to the overridden attributes of the class. This is both intended and can be overridden. It would be important to continue to pass off the webdriver instance in this example.

User Story draft.
As a user, I never want to think about passing off the driver instance to the page.

The goal of this issue mirrors the project stretch goal seen in GH-8, but revolves around adding support for the basic features of using XPath for HTML. I believe is impactful enough to warrant being in the MVP.

Acceptance:

• Add HTML core tags support
• Add HTML5 tags support
• Add the imports to the main module, so that users can import all tags.

TODO: Review if this needs to be broken up.

Need to add a way to select a data attribute

The goal of this project is to showcase how the pom-elements approach to creating PageObjects and Page Elements can make your life easier when working with any front-end frameworks. Additionally, it would not hurt to create an outline of how to implement this for a well known front-end framework.

To give an example of how this might work, the user could use from pom-elements.bootstrap import AlertSucces. From there the user could use all of the XPathElement features with success_message = AlertSuccess(text="FOO BAR"). Not every element in the library would be useful for PageObject Modeling, but it would allow users an easy way to see how to organize their Page Elements as well as as highlight the really powerful use case of the XPathElement class.

This project needs to get a build pipeline of some sort. Do I go super heavy into free and use Jenkins? Or do I give Actions a try?

User story:
As a developer on this project, I would like to know that this project meets a similar coding standard of other projects that I see online.

As this is more of a fun project, I am feeling like it would be really great to improve the checks on the PRs submitted via workflow. This allows me to spend a little time exploring some additional features available on Github. I see that other projects often have badges that show how great that they are. I want badges.....can I afford badges!???

Goals:

• Add badges to the README showing that automated checks have passed.
• Add on as many relevant and fun workflows that are available for this project.

Example projects: (https://shields.io/)

• COVERAGE: https://github.com/marketplace/coveralls/plan/MDIyOk1hcmtldHBsYWNlTGlzdGluZ1BsYW4zMDA=#pricing-and-setup
• ANALYSIS: https://www.codefactor.io/pricing

Please update the README to outline ways to set this project up easily.

The goal of this issue is to get pom-elements working with selenium Grid. The main benefit to getting this work would be to make sure that I am not designing a solution that does not work with a growing section of test automation. Additionally, I am interested in getting the github actions to check each PR and verify that the Selenium based browser tests in the tests/ directory pass. At a cursory glance, I believe that this can be done with a docker-based github action, or possibly a lower cost Github action that relies on using Selenium Grid.

TODO: Fill out the acceptance criteria for this issue. This may be more than one issue.

It would be really great to have api documentation for this project. I am currently interested in creating auto-generated docs, which will force me to have really nice doctrings, as well as be intentional with my updates. Additionally, I would like to maintain the Google Docstring format, which seems to influence the type of auto generated documentation tools available. There is an industry leaning towards using reStructured Text, https://docutils.sourceforge.io/rst.html, but I am leaning towards the use of Google doc strings.

Acceptance:

• Google docstring format are enforced on commits and PR merges.
• Enforce that Docsgtrings added to all classes and methods.
• Generate automated API documentation based on the work done with little manual overhead. Manually generated documentation is out of scope for this issue.

This issue is one of the last issues that needs to be done before moving this project to public. I will need to setup the ability to package this project. I am likely aiming for a platform independent wheel if that is possible.

An example.py file is an easy way to showcase how easy it is to get the project up and running. However, this may be best left up to the README.

The goal of this issue is to make sure that the vscode files are not getting in the way of other developers using another IDE or editor.

I have been a big fan of VSCode for a while. I have been really interested in sharing workflows around development environments. The approach is that standardizing workflows in an IDE may slow down one person, but it speeds up time for teams. It is a common goal to find, but I am finding that VSCode standardization is not the place to do this.....for now. At least this is my theory from larger projects and even toy projects like this one.

Alternatives:

• Setup pre-commit hooks
• Setup auto-formatters that people agree on.
• Add blocks to PRs that either do this work, or block PRs as they go.

The remaining issues for this project revolve around making sure that this thing is functional in a day-to-day usage. Users need to be able to select multiple elements at the same time, and users need the ability to dynamically get the majority of xpath selectors.

Acceptance:

• End users can select multiple elements at a time with a single command.
• Users are returned Page Elements classes.
• The xpath returning methods return more specific searches including text, html tags, data attributes, etc.
• A user can add several classes together.