feat(test): Adding betelgeuse docstrings to test_client.py

[zpetrace]

Adding betelgeuse docstrings to test_client.py

[Lorquas]

Looks good to me. How are you generating the test cases and/or adding them to the junit.xml with betelgeuse? I would like to test this out directly...

[ptoscano]

I would like to test this out directly...

Indeed -- this definitely needs to be tested with a github workflow/job, to verify that the format of these various comments, otherwise IMHO it's too easy to screw them up accidentally.

[Lorquas]

Other note, don't we need an :id: <uuid> field?

[Lorquas]

Update from slack convo:

• We're going to co-opt this PR and add a README for the various manual betelgeuse invocations
• This PR will be blocked by CCT-675 where we will attempt to add .github/workflow and other automations (using this branch as a starting point)

[ptoscano]

There is a bit of inconsistency in the various steps & results that talk about registering with insights-client:

Steps:

    2. Register insights-client
    1. Register the insights-client to generate log files
    2. Register insights-client and perform pazload operations
    1. Register the insights-client

Results:

    2. The insights-client registers successfully
    1. Insights-client is registered and log files are generated
    2. The insights-client registers successfully and logs are populated
    1. Insights-client is registrated
    1. Insights-client is registered

Ignoring the typos and the numbers, what I personally suggest is:

• keep the step & result to only mention the registration & its successfull result
• move other bits to own steps & results
• use a single wording, for example:
  • [step] Register insights-client
  • [result] Insights-client is registered successfully

This approach applies also to the testimony docstrings added in other PRs.

---

I see testimony validation failures for all the tests like the following:

test_client_files_permission:19
-------------------------------

* Tokens with invalid values:
  Tier: Tier 0
      type: choice
      case sensitive: False
      choices: ['tier 1', 'tier 2', 'tier 3']

I'm using the testimony.yml as currently available in #282, which has:

Tier:
  casesensitive: false
  required: true
  type: choice
  choices:
    - Tier 1
    - Tier 2
    - Tier 3

Hm, I wonder whether this seems like a bug in testimony...

[zpetrace]

I tried to get rid of the inconsistencies in wordings and also correct the typos etc. However I am not sure I understood

move other bits to own steps & results

However I am not sure I understood this part. If you can explain some more, please.

[zpetrace]

Hi @ptoscano, I have corrected the issues with the failing testimony. You can now use the current version of testimony after my last commit on #282. It now should look like this:

Total number of tests: 7
Total number of invalid docstrings: 0 (00.00%)
Test cases with no docstrings: 0 (0.00%)
Test cases missing minimal docstrings: 0 (0.00%)
Test cases with unexpected tags: 0 (0.00%)
Test cases with unexpected token values in docstrings: 0 (0.00%)
Test cases with unparseable docstrings: 0 (0.00%)

[zpetrace]

/packit retest-failed

[zpetrace]

I have changed the capitalization to the same format for every test as it was confusing. Hope that's better:)