feat: update test using definition file

[mathnogueira]

This PR makes the CLI update the test in case the id field is present in it.

Questions

• What should happen if the id doesn't exist in the server? Should the CLI fail or should we ignore it and create a new test?

Checklist

• tested locally
• added new dependencies
• updated the docs
• added a test

[kdhamric]

On "What should happen if the id doesn't exist in the server? Should the CLI fail or should we ignore it and create a new test?"

Can the system create the test with the given id (ie specify the id rather than let the system autodefine it)? If it can, I would create the test using the specified id.

[mathnogueira]

On "What should happen if the id doesn't exist in the server? Should the CLI fail or should we ignore it and create a new test?"

Can the system create the test with the given id (ie specify the id rather than let the system autodefine it)? If it can, I would create the test using the specified id.

Right now our backend doesn't allow this option. Everytime you call CreateTest, it assigns a new ìd to it.

[schoren]

Yes, the backend doesn't allow incoming IDs. Also, given that this is an update command, trying to update a non existing thing should be considered an error IMO

[mathnogueira]

Yes, the backend doesn't allow incoming IDs. Also, given that this is an update command, trying to update a non existing thing should be considered an error IMO

Just a correction there: Updating and Creating a test in the CLI are done by the same command. The decision of creating or updating the test depends on the value of the id on the test definition. If it is present, it becomes an update test request, otherwise, it would be a create test request.

I don't think the id should matter so much that the user might want to choose it. If the id is important, we should think about a human-readable id alias (kind of what confluence does with its pages). Now about the question, I think that behavior could be configurable. A suggestion would be:

1. Default behavior is that it creates a new test with a different id if the id specified in the test file doesn't exist (and it would print a warning on the output)
2. If the option --strict is provided, the behavior would change and it would fail

It could be the other way around as well: fail by default and allow the user to override that behavior

[kdhamric]

We need a good bit more planning and consensus building around the CLI. Lets keep things as basic as possible, doing a bare MVP. We will shift into planning mode next week.

[mathnogueira]

Sure. I'll keep it as it is then. The CLI will fail if an invalid id is provided.

[schoren]

LGTM!