Feature Request / Question: can the "external" calls be used outside the ITB UI?

[costateixeira]

There are a few "external" calls (apologies if I miss the language, I hope the intent is clear):

• Ask user to submit some data (for an interceptor)
• Ask user to submit some files (e.g. screenshots)
• Ask a "test monitor" to validate the results.

Are these exposed as API? Idea would be to allow another UI to notify user and capture the response to then send to the ITB services.

If not, could this be considered?

[costas80]

Hi @costateixeira. From your examples I understand you are referring to test cases that make user interactions such as a prompt to the tester with instructions or inputs, or a prompt to an administrator (whom you refer to as a test monitor). For such cases you would like to have an API call (like a webhook) that would call an external system, which would in turn:

1. Notify the user in question, present the test step's information and collect related inputs.
2. Call an API on the Test Bed to complete the step (with the collected inputs if the step expects them).

I assume your use case is using the ITB "headlessly" via REST API, with a different component implementing the tests' UI (if any).

The API calls you mention do in fact exist between the gitb-ui (user interface) and gitb-srv (test engine) components, but unfortunately these can't be "delegated" to another component acting as a "gitb-ui replacement". In contrast, a better approach would be to extend the interact step with a handler attribute, identical in meaning as the similarly named attribute on a send, receive, or verify step. This attribute would point to a service endpoint (much like a messaging service), that would receive a call when the interact step executes, and would pause until a response is returned. In practice this would work like the receive step, but for human interactions instead of service calls.

Something like this is conceivable but would require quite some work to be fully supported. This makes me think however that you could replicate exactly what you're going for with receive steps. When such a step is executed the test engine will call an external service with the inputs you've defined, and then pause until the response is asynchronously received. Nothing prevents you from using this step to drive user interactions instead (via an intermediate system) and achieve what you're going for. The only case I think where this would not work well is if you want to support both completing such interactions from the Test Bed's own UI as well as the external service/UI you are thinking of (but I doubt that's what you're going for as you are effectively looking to replace the Test Bed's UI).

What do you think of this approach (using the receive step to delegate user interactions to an intermediary system)?

[costas80]

To summarise a bit my previous comment, my suggestion would be to use the receive step for user interactions where you want the test session to pause for a response (e.g. provided inputs or a confirmation to a communicated instruction). You could also use the send step if you want "fire and forget" interactions where the test session will not block for user feedback.

Finally, if you want to support both the Test Bed's UI and the intermediary service managing interactions, you can do this. Define interactions in scriptlets (for encapsulation), in which you decide whether interactions use only the Test Bed's UI (i.e. using the interact step), use a delegated service (i.e. using the receive step), or both (making parallel interact and receive steps using a flow step). You could even manage what approach is followed via configuration (e.g. an if step checking a flag set as a domain parameter).