Best practices-based Python template for advanced use cases
A best practices-based implementation of the Robo Python Automation Framework for advanced use cases.
This template leverages the new Python open-source framework Robo, and libraries from the same project.
It provides the structure of an advanced Python project: building automation classes devoted to individual sites or components and combining them together into a task suite. The full suite includes the following features:
- Control Room-based JSON configuration provided via the Asset Storage solution
- A Pytest-based test suite targeting the automation classes, runnable via VSCode test extention, Robocorp Code extension, or
rcc
command in CI/CD, with Robocorp Log integration (see output folder after tests run). - A
WebAutomationBase
class which can be extended, allowing for common functionalities between different automations. - An internal Playwright locator dictionary with IDE support via the
prodict
package.
๐ After running or testing the automation, check out the output/log.html file.
This example has a significant amount of example code and comments and caution should be taken if you are adapting this directly into an automation for yourself.
We recommended checking out the article "Python Framework Introduction" before diving in.
Automation Classes
The example includes a package called libs
which includes examples of an Automation Class designed to automation the saucedemo.com test website. It inherits an abstract base class that describes some common methods any web automation class should have, such as login
. The abstract base class can be found in libs/web/__init__.py
.
Includes in the libs
package is an errors
module that creates an inheritence tree based on the base ApplicationException
and BusinessException
classes defined in robocorp-workitems
. By using these bases for all of the different errors within the automation, it is possible to automatically release errors from the automation to the Control Room without additional code.
Tasks
The robot is split into three tasks, meant to run as separate steps in Control Room. The first task generates (produces) data, the second one reads (consumes) and processes that data, and the third reports on the orders submitted.
The overall task package provides examples of the following features:
- A package of task modules, each with one or more tasks in it.
- A set of shared functions/constants in the package root, including a shared function that configures logging to log to console based on an environment variable called "LOG_LEVEL".
The first task (the producer)
The producer is located within the tasks.main_tasks
module.
- Load the example CSV file from work item
- Split the Excel file into work items for the consumer
- Provides an example of how to create output workitems with no inputs.
The second task (the consumer)
The consumer is located within the tasks.main_tasks
module.
We recommended checking out the article "robocorp-workitems" before diving in.
- Get credentials from the Control Room vault for the website based on a mapping within the Control Room Asset Storage
- Utilize the
Swaglabs
web automation class as a context manager to automatically handle login and logout to the website. - Loop through all work items in the queue as context managers, automatically handling errors raised within the process so they are released to the Control Room and do not cause the bot to completely crash in the middle of processing a queue of work items.
- Process each work item as a set of orders for a specific customer.
- Create an output work item summarizing the results for the reporter.
The third taks (the reporter)
The reporter is located within the tasks.reporter
module.
The reporter step should be configured in the Control Room with the setting Start Only After all work items from previous steps are either done or failed
because reporters generally are tasked with collating all work item results from previous steps.
- Loop through all Work Items in the queue, collecting key metrics from each.
- Create a final result output work item.
Final output work items can be used several ways within the Control Room, but primarily, they are useful as payloads in webhooks configured to be sent back to triggering systems at the end of the full process run.
Local testing
For best experience to test the work items in this example we recommend using our VS Code extensions. With the Robocorp Code extension you can simply run and select the input work items to use, create inputs to simulate error cases, and so on.
Additionally, the Automation Classes are optimized to be tested via Pytest using the VS Code test extension, you can read more about how that works here. The unit tests in this example are specifically defined in the tests
directory and are configured via a root pytest.ini
file and conftest.py
files within the test directories. Together, they allow the Swaglabs
class unit tests to operate. These unit tests are tagged so that those that perform operations on the test website online at www.saucedemo.com
are marked as live
.
NOTE These tests use the same environment built by the Robocorp Code extension as used by the robot tasks.
CI/CD Pipelines
In addition to local testing, included in the example is a set of pipeline files written for the four major online repository/project hosting sites, see the CI/CD readme for more information!
Extending the template
The producer-consumer model is not limited to two steps, it can continue so that the consumer generates further work items for the next step and so on.
๐ Now, you can just get to writing.
For more information, do not forget to checkout the following:
Technical information
Last updated
September 18, 2023License
Apache License 2.0