Would like to wrap my library using this code

douglasdcm commented 1 year ago

Summary

Hi, congratulations for your work. This is an amazing repository. I was checking the source code and I was wondering if it fits to a library I'm developing. It is used to run asynchronous requests against WebDrivers/Winium. I didn't find any unit test to help me to check it. This is the library. Let me know if you think it is possible to adapt/extend your code to use it, please. If it is possible, I'd be happy to play around and send some PRs related to it. Thank you!

Motivation

Why are we doing this? What use cases does it support? What is the expected outcome? I have a fresh library to interact with WebDrivers and Wnium, but the code I quite verbose. I think your code may make my library simpler to be used.

Describe alternatives you've considered

Use other repository to wrap my code or develop it by myself.

Chetan11-dev commented 1 year ago

Thanks, Douglas for the appreciation, you are the first one to acknowledge it. I have the following questions

What you like about Bose?
What problem does your library solves?
How will it help bose user's?

douglasdcm commented 1 year ago

Hi, here are the answers

What you like about Bose?

I liked that way it simplifies the boring task to write Selenium tests/crawlers. For example, to click on elements we always need to get these elements, so, for me the click method in Selenium would be smart enough to get and click. I would make the developer interface less verbose and we wouldn't need to wrap the things in Page Objects or other structures. Your library does it. It condenses the related methods in less lines of code, which is perfect, because it reduces the responsibility of the tester. It reduces the maintenance and errors. As people use Bose more and more, they will find issues, that are common for many testers, so the fix is shared across the community.

What problem does your library solves?

It is intended to command executions against Drivers synchronously and asynchronously. Launch the Driver as a server and send requests to it. The intention is that the user does not worry about which Driver he/she is using. It can be WebDrivers like Selenium, MobileDrivers like Appium, or DesktopDrivers like Winium (this was copied from my README :) So, the basic idea is have one single library to interact with many UI controllers. Selenium is just intended to be used with Web pages, Winium with Windoes Descktop and Appium in mobile tests. Each time we change the stack we need to change the library/methods we use. I've tested my library with ChromeDriver, Firefox and Winuim, but I have plans to extend it. Other key feature is the possibility of run asynchronous and remote calls to these webdrivers. Asynchronous make the tests faster and it can be executed with many driver instances, so no need to use Selenium Grid. The Remotpart is related to infrastructure. The team can have just one server with a controlled WebDriver running, hence the tester/developer does not need to build the local environment by herself.

How will it help Bose user's? I think it helps Bose user to use an async/remote/agnostic library using a friendly interface. As I say, may library is quite verbose, so the user will find herself doing things like "open session", "get element", "click", "close session". I have to admit it is boring

Let me know you have more questions. :)

Chetan11-dev commented 1 year ago

@douglasdcm

Thank you for sharing your thoughts. I believe the use case you mentioned is not commonly needed, and therefore, I have decided not to incorporate this functionality. However, I encourage you to feel free to fork the project and make any modifications you deem necessary according to your library's requirements.

douglasdcm commented 1 year ago

No problem. I'll add it to my plans. I think your code is a good staring point to it. Thank you!

omkarcloud / botasaurus