Deciding the test flow is crucial while creating YAML test files. Different endpoints can be added as modules for end-to-end real world scenario replication. The test flow for each TES API endpoint is described below.
The service info endpoint is independent of others and can be invoked alone.
- Get Service Info
GET /service-info
A task must be present while fetching the list of tasks. Hence, creating a task beforehand is necessary.
- Create a new task
POST /tasks
- Get list of tasks
GET /tasks
A task must be present while fetching it. Hence, creating a task beforehand is necessary.
- Create a new task
POST /tasks
. The ID will be stored in auxiliary space. - Get the task by ID
GET /tasks/{id}
A simple logical test would be just sending the request to create a new task. However, a more detailed validation
will be GET this task by ID and monitor the task status inside the TES server. If the task returns an appropriate
status from ["COMPLETE", "EXECUTOR_ERROR", "SYSTEM_ERROR"]
, then its successful.
- Create a new task
POST /tasks
. The ID will be stored in auxiliary space. - Get the task by ID
GET /tasks/{id}
A task must be present in order to be canceled. Hence, creating a task beforehand is necessary. A simple logical
test would be just sending the request to cancel the task. However, a more detailed validation will be GET this
task by ID and monitor the task status inside the TES server. If the task returns an appropriate status
from ["CANCELED", "CANCELING"]
, then its successful.
- Create a new task
POST /tasks
. The ID will be stored in auxiliary space. - Cancel the task
POST /tasks/{id}:cancel
- Get the task by ID
GET /tasks/{id}