Running in CI/CD isn’t really different from running (Python) unit tests; Robot Framework is a Python package, just like e.g. pytest. So it’s just a python -m robot <args> instead of e.g. python -m pytest <args>.
For web automation, you can use SeleniumLibrary or Browser. The former is Selenium-based, the latter is PlayWright-based. I’m not too familiar with macOS Desktop app automation, others may be able to suggest libraries for that.
No, I’m not suggesting using pytest to test Robot Framework suites, I’m indicating that running Robot Framework suites in a CI/CD is no different from running pytest in CI/CD. The commands are virtually the same.
When it comes to good test practices, there’s many layers to it. For example web testing:
First, there should be unit tests on the frontend code (most likely JS/TS). Those generally run with many mocks / stubs.
Then there should be functional level tests; going through the application flows. This could be ran on a version of the site that “talks to” a mocked backend.
But then there’s integration; you’ll want to verify that the functional tests also work on the site that’s talking to an actual backend.
For (native) app testing, you’ll indeed need to have some host, VM or container with the target application installed. In addition, you’d install Python and the desired packages (RF and the libraries of choice) and run the tests.
You don’t write tests to run on CI/CD, you write tests that work fine on your local machine, and then configure your CI/CD to have the conditions to run them.
For example, if using SeleniumLibrary, then the CI/CD machine must have the proper webdriver, and the browser installed. If using headlessbrowser, then there is no need to have a GUI environment.
When testing a macOS app, then you need to have a real machine as a node of your CI/CD. I do this with Jenkins, where my macOS node is connected with the java client, and has the testing automation user always logged in. Of course, your setup may have to be different.
Yes, it is straight forward. If you defined a variable for your browser just change it to the headless corresponding name. For example robot -v browser:headlesschrome ...
You only may need to adjust timings with Wait ... keywords. If you test first in local system, it should behave the same in CI/CD system.
This is in-house solution, real hardware macMini as a node of Jenkins. But use it for testing with Safari and Appium (Android and iPhone), macOS apps never tried because not needed (but would go for Sikuli as first try).
Yes, that is the current maintained version (and it is on GitHub now , I did not know).
But that is the original framework, which I recommend to try and use, before using the Robot Framework wrapper, here.