UI Integration test boundaries - nested api calls

Question

I am developing the UI of an e-commerce. Actually it is the checkout page only. The entrance URL looks like this: myEcomerce.com/{orderGuid} On load The ui takes the orderGuid as parameter to call the API and get the details. In other words, UI call getOrderDetails passing the orderGuid.

My main concern is in relation with the Testing strategy used to integrate UI and API. For an automation test, I will need a valid orderGuid.

We already had a discussion between UI and API teams. API offers an extra endpoint to create an Order in order to get a valid {orderGuid}

My integration tests in the ui could be...

1. call createOrder (only to get a valid order id)
2. call getOrder
3. populate the view
4. asserts..

The UI never will consume this endpoint (createOrder) in production, in fact, this endpoint is consumed by other api client....

UI is forced to work in this extra endpoint (createOrder) if they want to integrate with API. You could imagine this new extra maintenance effort. Deal with the order creation could not be easy.

I believe the API should provide a "Sandbox" environment and a list of valid {orderGuid}s for multiple testing propose. Instead of push this complexity to the consumer.

I do not pretend UI deals with the Order creation only for testing propose. Whatever change in this order creation process is going to affect our hundreds tests making them really fragile. I believe we are not going in the right direction if we need to call the order creation from the UI to retrieve a valid {orderGuid}

Any better idea to deal with the integration tests?

Answer 1

I agree with your reasoning. If UI never creates an order in production, your UI tests shouldn't be doing it.

Yes, the test environment should be mocked or initialised in a state ready for the UI tests to run.

I see this as a parallel to a use case for, say, testing a user creating a post on a blog - if the UI portion under test is not responsible for creating that user, then it should be given a test environment where a valid user exists and then simply attempt to create a post with that user.

Given this is an integration test, if the API team have built the API such that you cannot test your UI unless a valid order exists, then there needs to be a mechanism to initialise the test environment API such that your code can run on it.

(and that mechanism shouldn't involve re-inventing a whole other section of the UI)