Sto sviluppando l'interfaccia utente di un e-commerce. In realtà è la sola pagina di pagamento . L'URL di ingresso è simile al seguente: myEcomerce.com/{orderGuid} In caricamento L'interfaccia utente accetta come parametro l'orderGuid per chiamare l'API e ottenere i dettagli. In altre parole, l'interfaccia utente chiama getOrderDetails passando orderGuid .
La mia preoccupazione principale riguarda la strategia di test utilizzata per integrare UI e API. Per un test di automazione, ho bisogno di un orderGuid .
validoAbbiamo già avuto una discussione tra i team di interfaccia utente e API. L'API offre un endpoint aggiuntivo per creare un ordine al fine di ottenere un {orderGuid} valido
validoI miei test di integrazione nell'interfaccia utente potrebbero essere ...
- chiama createOrder (solo per ottenere un ID ordine valido)
- chiama getOrder
- popola la vista
- afferma ..
L'interfaccia utente non consumerà mai questo endpoint ( createOrder ) in produzione, infatti, questo endpoint viene utilizzato da un altro client API ....
L'interfaccia utente è costretta a lavorare su questo endpoint aggiuntivo ( createOrder ) se desidera integrarsi con l'API. Potresti immaginare questo nuovo sforzo di manutenzione extra. Affrontare la creazione dell'ordine non potrebbe essere facile.
Credo che l'API dovrebbe fornire un ambiente "Sandbox" e un elenco di {orderGuid} validi per più test proposti . Invece di spingere questa complessità al consumatore.
Non faccio finta che l'UI abbia a che fare con la creazione dell'ordine solo per la proposta di test. Qualunque cambiamento in questo processo di creazione degli ordini influenzerà i nostri test a centinaia rendendoli davvero fragili. Credo che non stiamo andando nella giusta direzione se dobbiamo chiamare la creazione degli ordini dall'interfaccia utente per recuperare un {orderGuid} valido
Qual è l'idea migliore per affrontare i test di integrazione?