Limiti del test di integrazione UI - Chiamate API nidificate

0

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 .

valido

Abbiamo 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

valido

I miei test di integrazione nell'interfaccia utente potrebbero essere ...

  1. chiama createOrder (solo per ottenere un ID ordine valido)
  2. chiama getOrder
  3. popola la vista
  4. 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?

    
posta Market 22.04.2018 - 11:54
fonte

1 risposta

0

Sono d'accordo con il tuo ragionamento. Se l'interfaccia utente non crea mai un ordine in produzione, i test dell'interfaccia utente non dovrebbero eseguirlo.

Sì, l'ambiente di test dovrebbe essere deriso o inizializzato in uno stato pronto per l'esecuzione dei test dell'interfaccia utente.

Vedo questo come un parallelismo con un caso d'uso per, diciamo, testare un utente che crea un post su un blog - se la porzione UI sotto test non è responsabile per la creazione di quell'utente, allora dovrebbe essere dato un ambiente di test dove esiste un utente valido e quindi cerca semplicemente di creare un post con quell'utente.

Dato che si tratta di un test di integrazione, se il team API ha creato l'API in modo tale che non è possibile testare l'interfaccia utente a meno che esista un ordine valido, è necessario un meccanismo per inizializzare l'API dell'ambiente di test in modo che il codice possa essere eseguito su di esso.

(e quel meccanismo non dovrebbe comportare la reinvenzione di un'intera altra sezione dell'interfaccia utente)

    
risposta data 22.04.2018 - 15:56
fonte

Leggi altre domande sui tag