Weird Tescase structure design in the rxtst file and report
Posted: Mon Apr 03, 2017 1:18 pm
The Test Suite structure only supports Folders and Testcases.
IMHO, this is not good enough.
There needs to be a third type called Step.
Here's why:
The actual structure of a test case is that it can contain steps (1, 2, 10 steps, etc, and steps can potentially contain sub steps, etc).
Currently, you can only achieve this by nesting Testcases inside eachother, or placing testcases in a folder, but there are several disadvantages to this:
1. The nested testcase AND the parent testcase are all counted in the total tally, giving a misleading final count of Passed/Fail. (brought up but rejected in the forum post "counting-passed-failed-test-cases-correctly")
2. Folders lack the features that Test Cases have (most notably, Setup/Teardown), because they're just that...folders.
Maybe you're thinking that the Recording module solves this by letting you add "actions" insead of steps, but this is an awkward solution. Also, if you use databinding, the entire set of actions are repeated, which may not be intended.
All in all, the current model is too inflexible for us, and produces reports that are ultimately unreadable for us.
If there is a way around this without changing the current model, I'm all ears.
IMHO, this is not good enough.
There needs to be a third type called Step.
Here's why:
The actual structure of a test case is that it can contain steps (1, 2, 10 steps, etc, and steps can potentially contain sub steps, etc).
Currently, you can only achieve this by nesting Testcases inside eachother, or placing testcases in a folder, but there are several disadvantages to this:
1. The nested testcase AND the parent testcase are all counted in the total tally, giving a misleading final count of Passed/Fail. (brought up but rejected in the forum post "counting-passed-failed-test-cases-correctly")
2. Folders lack the features that Test Cases have (most notably, Setup/Teardown), because they're just that...folders.
Maybe you're thinking that the Recording module solves this by letting you add "actions" insead of steps, but this is an awkward solution. Also, if you use databinding, the entire set of actions are repeated, which may not be intended.
All in all, the current model is too inflexible for us, and produces reports that are ultimately unreadable for us.
If there is a way around this without changing the current model, I'm all ears.