I can prove test execution

Historical behaviour

As of today, comment associated to a test execution is strongly associated to the recording of the status (passed/failed/blocked). It means that text executor is supposed to:

1. notice a that the test/step is, for instance, failling
2. write a comment
3. click on "failed" to record both the failure as well as saving the comment

More than often though, the actual steps are:

1. notice a that the test/step is failling
2. click on "failed"
3. add a comment about the failure
4. click again on "failed" to save the comment

New behaviour

It should be possible to edit/change a comment in order to:

• be more specific about the failure mode
• clear / rewrite comment because the test was re-executed

This means a decoupling between the comment and the status. This introduce the risk of having a comment no longer aligned with the status. The main risk is the following sequence:

1. Alice mark the test as failed
2. Edit the comment to inform about the error she got and add evidences about the failure
3. Bob try to re-run the failed step but this time it works
4. Bob mark the test as Passed but the comment was not edited
5. Now the comment refers to an error (alice error) but the test actually passed => inconsistency

Acceptance criteria

In order to support the new use cases while limiting the risk of inconsistency:

• As soon as a comment is saved, the comment box turns read only (grayed)
• If someone wants to modify a comment, they must click on "Edit comment"
• Saving the comment can be done with "Save comment" button
• Changing status with comment section in edit mode saves the comment
• If a comment is set and the status is something else than "Not run", then changing the status without changing the comment raises a warning:
  • With Alice and Bob example, at step 4, Bob's is told that he should look at the comment because it's likely to be outdated.
  • The warning is displayed only to the test executor and only when they change the status (pure front-end). If tester reloads the page for instance, the warning will be gone.

Business rules must be enforced in front-end, backend (API) and realtime.

For instance, for API/Backend:

• Given Alice saves a comment on a test
• When Bob loads this test
• Then Bob see the comment box with Alice comment in read only

For instance for realtime:

• Given Alice loads test exec "my fine test"
• And Bob also loads test exec "my fine test"
• When Alice save a comment on the test
• Then Bob sees the saved comment, in read-only, without having to reload the page.

Realtime triggers synchronization when the comment is saved:

• Either with "Save button"
• Or with Change of status

The old display of comment (at top) is removed as it's now displayed at the bottom of the test.