Convert To Title Case was added in RF 3.2 (#2706). Unfortunately its not fully compatible with the old Should Be Title Case keyword. For example, the second test below fails with 'This Is Not OK!' is not titlecase.:

*** Settings ***
Library        String

*** Test Cases ***
Passes
    ${title} =    Convert To Title Case    This is ok.
    Should Be Title Case    $

I'm trying to automate the interaction with WindowsTerminal. It seems to be a UWP application, which I have no idea how to start such application directly using Application().start. I've tried to locate it using Desktop, but got quite confused..

Any help on this?

It's nice if testing doesn't produce unnecessary artifacts after running with success but keeps relevant info on fail for further inspection.

Pytest should have a nice way of creating fixtures that can post-process a test based on whether it failed or not https://docs.pytest.org/en/latest/example/simple.html#making-test-result-information-available-in-fixtures

If a test fails, then keep the

https://github.com/agriffis/vcrpy-unittest adds a VCRTestCase (and a VCRMixin) class. They consists only of 23 lines of code. Please include those two functions in your project to avoid needing to install another package. Those tiny package have a bigger overhead and packaging them for Debian would be rejected due to this reason.

While inspecting the installer, I noticed the fallbacks for Linux / OSX when appdirs isn't available (in data_dir()).

Wouldn't it make sense to add an if for Windows based on %APPDATA% or %LOCALAPPDATA%, before resorting to globally installing appdirs?

Running 2.9.1 (yes, I know, it's old). We have several different clusters, but don't have the same k8s deployments in each cluster. Tried to use a generic policy definition. When it is applied in a cluster which doesn't have one of the deployments, seal doesn't handle the 404 from k8s and dies. Yes, we can change the policies, but also seal shouldn't die in this scenario.

While this was wit

Hello, and thank for this module.
I am wondering if consideration has been given to adding colour to the stack traces printed out upon failure of a test. For a test runner emphasizing colour, this seems like an obvious omission. I have patched in this functionality using pygments in my fork: psacawa/green@1922bc8 in an ad hoc fashion t