0

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?

  • 1
    "the UI never will consume this endpoint in production" then it shouldn't consume it in the tests. I do not understand why you think it needs to. – Stop harming Monica Apr 22 '18 at 11:43
  • "UI is forced to work in this extra endpoint integration if they want to integrate UI with API." looks like a direct contradiction to "the UI never will consume this endpoint in production" to me. Please clarify. – Doc Brown Apr 22 '18 at 12:23
  • Let me clarify, UI displays a checkout page, to do that, UI calls get order service from the API sending the orderGuid as a parameter. API returns the order details dto and UI populates the view. To recreate this scenarios with an integration test, I should provide a valid orderGuid At this stage is where the UI is forced to "create a valid order" to get a valid orderGuid. API exposes createOrder to do that. @DocBrown the ui never will call the createOrder in production. But if we go in this direction, I should maintain an extra call (createOrder) only for testing propose – Market Apr 22 '18 at 13:20
0

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)

  • Could you provide academic resources to support it? – Market Apr 22 '18 at 17:55
  • I don't know of any that cover this case. It's fairly context specific, but the basic principle is you shouldn't be spending time debugging your tests - which means that the setup for the test should be as simple and straight forward as possible. If POST /orders is simple enough, then the API team might be able to argue that's the easiest way to get tests going, but if, as you seem to say, it's multi-step and prone to change then there should be an easier way to set up your tests. – ChristopherJ Apr 22 '18 at 23:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.