Un tester dell'automazione dovrebbe conoscere i concetti di OOPS e gli schemi di progettazione per scrivere i test in un modo in cui i cambiamenti e l'amp; è possibile riutilizzare il codice?
Ad esempio, prendo Java per scrivere definizioni di passi cetriolo che istruiscono un webdriver di selenio.
Dovrei usare molta ereditarietà, interfacce, delega ecc. per semplificare la vita o sarebbe eccessivamente complicato per qualcosa che dovrebbe essere solo una linea per riga?
Il codice di test è un codice che deve essere letto, eseguito e gestito, proprio come il codice di produzione, quindi dovrebbe essere sottoposto agli stessi standard del codice di produzione.
Usa semplicemente l'ereditarietà, le interfacce, tutto il resto, dove ha senso e dove ti aiuta a costruire uno script di selenio gestibile.
P.S .: il PageObject è un pattern comunemente usato per il selenio, dove si crea una classe che espone i pulsanti, i campi, ecc. Di una pagina come proprietà e metodi di una classe. Vedi PageObjects per ulteriori informazioni.
Non c'è "dovrebbe". Il test è uno strumento. È come chiedere "Se un artista usa sempre la vernice a base di olio". La risposta è (ovviamente!) "Dipende".
L'obiettivo dei test è di a) testare il prodotto e b) essere ben progettato. Puoi scrivere prove ben progettate in molti stili. La tua squadra dovrebbe fare ciò che è più compatibile con le loro abilità.
Questa decisione dipende dal tipo di test che vorresti fare, ad esempio testerai il progetto una volta e dimenticandolo. In tali scenari, utilizzando un modello di progettazione come Oggetti pagina non ha senso. Ma se lo scopo è quello di costruire una libreria di regressione che necessiti di manutenzione e la necessità di aggiungere ulteriori test che proiettano, allora ha perfettamente senso usare un solido design. Un buon design è utile anche quando vuoi testare le continue build di integrazione.