Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support having multiple tests with same TestRail case id #161

Open
ljessendk opened this issue Sep 11, 2023 · 3 comments · May be fixed by #163
Open

Support having multiple tests with same TestRail case id #161

ljessendk opened this issue Sep 11, 2023 · 3 comments · May be fixed by #163
Labels
enhancement New feature or request

Comments

@ljessendk
Copy link

What would you like the TestRail CLI to be able to do?

When multiple JUnit tests point to the same TestRail case id I would like TestRail CLI to mark the test as failed if at least one of the tests fail.

Why is this feature necessary on the TestRail CLI?

To support JUnit parameterized tests.

As an example, the following very simple parameterized JUnit test:

`import static org.junit.Assert.assertEquals;import org.junit.jupiter.params.ParameterizedTest;
import org.junit.jupiter.params.provider.ValueSource;
import com.testrail.junit.customjunitxml.annotations.TestRail;

public class SimpleTest {
@ParameterizedTest
@testrail(id = "C1234")
@valuesource(ints = {1, 2})
void isTwo(int number) {
assertEquals(2 , number);
}
}`

Will result in an output with two entries with the same "test_id" property value. The first test fails, while the second succeeds.
Running 'trcli' will mark the test as passed, but the result I have hoped for is that the test is marked as failed (logical AND).

More details

No response

Interested in implementing it yourself?

Yes

@ljessendk ljessendk added the enhancement New feature or request label Sep 11, 2023
@bitcoder
Copy link
Collaborator

  1. Supporting multiple TR case ids is being tracked on Need support for adding multiple testrail case IDs in single test #130.
    However, your feature request is slightly different from what is in the title. The feature you're looking for is on supporting parametrized tests. I'll update the title to make it clear ok?

  2. In the your use case, the Test Run will have two tests: one passing and another failing, right?

  3. You would like just to have one test in the Test Run, where status would be based on some logic (e.g. all iterations passed => status will be pass). Is that it?

@ljessendk
Copy link
Author

  1. Supporting multiple TR case ids is being tracked on Need support for adding multiple testrail case IDs in single test #130.
    However, your feature request is slightly different from what is in the title. The feature you're looking for is on supporting parametrized tests. I'll update the title to make it clear ok?

So #130 is when you have one JUnit <testcase> entry that maps to multiple TestRail case ID's (one-to-many mapping). The feature I am looking for in this feature request is the other way around: Multiple JUnit <testcase> entries that maps to a single TestRail case ID (many-to-one mapping).
Parameterized tests is one use case we have that results in a many-to-one relation, however splitting a test into multiple test methods could also be a valid use-case that could be covered by this feature request, this is why I opted for a title that did not include 'parameterized tests'. But I am ok with you changing the title if that makes it more clear.

  1. In the your use case, the Test Run will have two tests: one passing and another failing, right?

Yes, correct.

  1. You would like just to have one test in the Test Run, where status would be based on some logic (e.g. all iterations passed => status will be pass). Is that it?

Yes, correct.

@Geoffrey-Hagberg
Copy link

I'll second this request; my organization is mapping a backlog of existing automated tests to a backlog of existing manual regression cases, and we've got some scenarios where that mapping is multiple tests to one case (as documented in this issue) and some scenarios where that mapping is one test to multiple cases (as covered by #130).

I'm excited for the solution to #130 to be released! But wanted to bump this issue as the other half of what my org would need to allow us to handle all our potential scenarios! Happy to provide more context for those scenarios, if that would help clarify priority.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants