> On Mon, 2015-11-23 at 10:36 -0500, Kamil Paral wrote: > > > Oh, one more thing - similarly to _bios and _uefi test cases, I'd > > like to change existing _workstation_encrypted test case to just > > _encrypted test case - it shouldn't matter which package set is > > installed to verify that there's no issue with unlocking your drives. > > This way you can easily fill 3 test cases with just a single test > > (e.g. minimal + encrypted + bios). > > Just be aware that the upgrade test cases are based on templates, > please don't break that setup as it saves a lot of work in duplicating > content between all the various upgrade tests. I understand why you > want to make the changes in the way you do, but I do think it'd be nice > if possible to always treat UEFI vs. BIOS as an 'environment' > difference, i.e. in the result columns, not in the test case name. > > As an alternative perhaps we could have workstation_encrypted (or 'any > package set encrypted', if I can tweak the template a bit) with BIOS > and UEFI columns, and other tests with just x86 and ARM columns? Hmm, the environments as columns work well if we want to test all combinations, but not that well if we want to test it just once, for any test case. I'd really like to say "if you have tested upgrade with uefi, whatever package set or configuration, you can tick this box", and not "tick this box only if you have tested _encrypted_ installation with uefi". That puts additional constraints on testing, and it seems to me that it's better to live with two additional lines (_uefi and _bios) rather than changing our testing to accommodate a nicer 2D structure of the matrix. As a middle ground, what about having: .---------------------------------------------------. | BIOS UEFI| |Testcase_upgrade_dnf_previous_any | '---------------------------------------------------' I think that's reasonable? Maybe we don't even need to modify and use the template content, just reference other test cases and say that any of them is fine. -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@xxxxxxxxxxxxxxxxxxxxxxx
