Closed Bug 665116 Opened 13 years ago Closed 13 years ago

warn the user when they try to add 2 suites to a run and they each contain different test case versions

Categories

(Mozilla QA :: Case Conductor-Platform, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: camd, Assigned: vadimk)

References

Details

Given SUITE-1 has TC-1, version 1 and SUITE-2 has TC-1, version 2: if you try to add SUITE-1 and SUITE-2 to a test run, there will be a conflict, it doesn't know which version to add for TC-1.

This would be the ideal fix: (from Carl Meyer)
a. To have a latestVersionWins option we can pass to the suite-adding call
b. If the latestVersionWins option is not used, the error message should name which test case had the version conflict.

That'll give us the flexibility we need. I can first try without latestVersionWins, and if I get that error back I'll have the data I need to warn the user, and I can immediately re-submit with latestVersionWins.
Blocks: 665119
This is a contradiction to the issue 665108, which asked to just skip conflicting test case from the second test suite and was already implemented.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
(In reply to comment #1)
> This is a contradiction to the issue 665108, which asked to just skip
> conflicting test case from the second test suite and was already implemented.

There was no contradiction, the two bugs were not for the same situation. Bug 665108 specifically stated "This is if the test case version is the same for both" - i.e. platform was returning the conflict error even when there was no conflict, because it was the same test case version being added again.

The current fix for 665108 fixes that problem, but goes too far - now the first version added wins in all cases (rather than latest-version-wins, which would be a more useful automatic algorithm), and actual version conflicts always pass silently. This behavior was never requested. Thus this bug is still relevant for actual version conflicts.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
OK, I made the following changes:
1.If old and new test case is of the same version, then new one is quietly ignored.
2. If testRun.useLatestVersions is True and if old test case is the later version then new one is quietly ignored.
3. If testRun.useLatestVersions is True and if new test case is the later version then the old one is removed from test run and new one is added.
4. If testRun.useLatestVersions is False then this is thrown
IncludingMultileVersionsOfSameEntityException("TestCaseVersion : " + testCaseVersionId_)

BTW, there is no need to create new parameter "latestVersionWins", because we already have "useLatestVersions" property at a test run level, which could be set during creation or updated later....
Status: REOPENED → RESOLVED
Closed: 13 years ago13 years ago
Resolution: --- → FIXED
Hmm. I'd been planning to use the latestVersionWins parameter in a transient per-request way, because the behavior Cam had requested was to have the latest version win, but warn the user anytime a version override occurred. So I was going to first make the request with latestVersionsWins false, then if an error came back, warn the user and immediately request again with latestVersionWins true.

This technique doesn't work well with the testRun.useLatestVersions parameter, which ought to be a more persistent characteristic of the testRun; I'd have to constantly flip it back and forth, which is kind of weird.

So verifying this as fixed, because the functionality is there; just not sure if there'll be a good way to provide the requested user warnings. Cam, you can weigh in on how important that is.
Status: RESOLVED → VERIFIED
I think, it should be a strategic decision on test run construction level and not a per-request scenario. Users should know what strategy they employ when creating test runs. So, going back and forth should never happen between requests. It's either allow it in all cases or not at all...
We can survive without the warning.  Seems like that would have been nice, to give the user a heads up that they may need to update their test suite, though.  This may end up being a polish issue, once the product gets more use.  Though it may be something that nobody notices or cares about.  Hard to say.
You need to log in before you can comment on or make changes to this bug.