Yes, the testcase suggests crond, but I suggested chronyd. I have had trouble in the past trying to use crond on some systems (cloud, I think, although it was a long time ago). However, I have never had an issue using chronyd, and it has become my go-to service to use when testing this testcase.
I'm not interested in rewriting this testcase, I feel that the current format is fine. This mail is simply to suggest changing the default service that the testcase uses. If we can figure this out, then perhaps we can discuss reformatting the structure of the testcase, but let's do one thing at a time.
Geoff Marr
IRC: coremoduleOn Thu, Apr 16, 2020 at 9:22 AM Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> wrote:
On Thu, 2020-04-16 at 13:09 +0200, Kamil Paral wrote:
> On Wed, Apr 15, 2020 at 7:41 PM Geoffrey Marr <gmarr@xxxxxxxxxx> wrote:
>
> > I have tested Fedora IoT, Cloud, workstation on both ARM and x86_64,
> > everything this testcase blocks on, and they all include chronyd.
> >
>
> The testcase doesn't suggest chronyd but crond. So which one are we talking
> about here? I tend to consider crond more important, and if we pick an
> alternative, I'd pick crond (if it's installed everywhere). I have no
> issues with replacing sshd in the testcase.
>
> If you get to rewriting the testcase, can you please restructure it a bit
> as well? The Expected Results section is dumb, especially the "The expected
> results, in order, are:" part. You can't just follow step by step
> instructions, you have to constantly jump between How To Test and Expected
> Results and try to figure out what outcome is expected at that moment.
> Ideally, each step in How To Test should be clear about the expected
> outcome, so you can really go sequentially one by one and immediately know
> when something broke. The Expected Results section would only list those
> requirements which are not specific to particular steps but are valid
> overall for the whole test case, or it doesn't make sense to put them in
> How To Test for some other reason. I tried to use this approach in my
> latest testcase [1] (there was nothing to put in Expected Results, but the
> section mustn't be empty, so I used a somewhat unneeded sentence in there).
> Can you try something similar?
>
> Thanks!
>
> [1] https://fedoraproject.org/wiki/QA:Testcase_desktop_app_basic#How_to_test
If we're gonna write test cases like that, we should probably just have
an alternative template, or an alternative "mode" for the template we
have. I don't like using a template which clearly expects the "Here are
the steps, and here are the expected results" format but actually uses
"Step 1, step 1 expected result, step 2, step 2 expected result..."
format. Writing templates isn't that hard, so I feel like that would be
nicer :)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
_______________________________________________
test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/test@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________ test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@xxxxxxxxxxxxxxxxxxxxxxx
