Mock Objects for Testing - Test Automation Engineer Perspective

Ciao.
Prima domanda: vuoi utilizzare i framework xUnit, i framework mock e il codice di scrittura?

Se no, non preoccuparti. Il 90% dei lavori per i tester non include la scrittura del codice, quindi se non è qualcosa che stai cercando, puoi saltare questo insieme di conoscenze.

D'altra parte, se ti piace scrivere codice, in qualche modo non pensi di essere uno sviluppatore, c'è la possibilità di lavorare sull'automazione dei test che richiederà abilità di codifica. Un particolare linguaggio di programmazione dipenderà dallo stack di pedaggi / applicazioni, ma ti verrà richiesto di scrivere il codice.

Come per i framework xUnit, probabilmente non si scriverà il test unitario (come detto lavoro di sviluppo), ma è possibile che li userai come runner per i tuoi test. Ad esempio il Selenio che è stato menzionato qui non richiede abilità di codifica se usi SeleniumIDE che è solo uno dei prodotti. Se usi SeleniumCore, allora stai usando api che avvolge il browser. In questo caso si scrive codice che eseguirà i test su una determinata applicazione. E se metti questo codice nel framework xUnit avrai runner, rapporti con esso.

Per quanto riguarda gli oggetti finti li userete in situazioni molto rare. Forse quando costruirai un framework di automazione per la tua app. Ma a seconda dell'approccio, puoi saltarlo.

Modifica Come da nuove risposte e modifica della domanda principale. Sono d'accordo con c_maker - probabilmente non scriverete i test unitari per il codice dell'applicazione, ma è possibile scrivere test unitari per il vostro software di automazione framework sia software che software, se si sta testando software di altri software. Anche in questo caso, come ha detto c_maker, se hai scritto test di livello gui con selenio usando selenio - quelli sono test di accettazione e non test unitari.
In ogni caso, controlla i seguenti link in modo da capire come funziona il lavoro di potrebbe per l'ingegnere dell'automazione di test:
 - Rapida panoramica
 - Grande spiegazione
 - Ispirazione per tutto quanto sopra e pochi pdf che lo descrivono

Risposta breve : dipende dall'organizzazione.

Risposta lunga : senza sondare tonnellate di aziende, è difficile quantificare come i team di QA spesso siano coinvolti con test di scrittura che coinvolgono oggetti finti. Nella mia esperienza, la maggior parte delle piccole e medie aziende di sviluppo software tendono ad appoggiarsi ai propri sviluppatori per scrivere unità, integrazioni e test dell'interfaccia utente. I dipartimenti di controllo qualità di tali aziende di solito testano nuove funzionalità e miglioramenti, nonché se i difetti sono stati risolti (idealmente, i test stanno facendo questo, ma in pratica, non tutti gli sviluppatori scrivono un test per verificare il difetto appena risolto). p>

Molte aziende più grandi impiegheranno team di assicurazione della qualità con esperienza di programmazione. Tali team sono noti per scrivere test dell'interfaccia utente (come Selenium per le applicazioni browser) in quanto tali test non richiedono la conoscenza del codice per verificare la funzionalità; I test dell'interfaccia utente in genere controllano le risposte UI previste rispetto alle risposte effettive.

In alcuni casi, il team addetto al controllo qualità contribuirà anche a scrivere test di unità e di integrazione, sebbene nella mia esperienza sia raro vedere che il QA sia completamente responsabile di tali test. In genere, sarà più facile per gli sviluppatori scrivere test. Detto questo, un membro del team di controllo qualità che illustra la comprensione del codice e la capacità di scrivere test di unità e integrazione (compreso l'utilizzo di oggetti mock per tali test) diventerebbe rapidamente un leader in tale dipartimento.

Raccomandazione : dovresti concentrarti sull'apprendimento della buona progettazione e delle pratiche dell'interfaccia utente, sulla verifica di casi comuni e limitati e ottenere una comprensione delle esperienze e delle aspettative degli utenti in generale come base per la tua carriera di QA. Tuttavia, conoscere il lato dello sviluppo del QA (cioè scrivere test con e senza oggetti finti) aiuterà sicuramente la tua carriera. Se hai tempo, imparalo.

Ecco un paio di punti per cui il QA non può e non deve scrivere test unitari:

• I test unitari sono estremamente vicini al codice di produzione. Per scrivere test di unità è necessario capire che cosa fa esattamente il codice. Di solito le persone con il QA non hanno le qualifiche per questo. Se lo facessero, sarebbero sviluppatori.
• I test unitari si evolvono anche con il codice. Devono cambiare quando il codice cambia e devono essere impegnati per il controllo della versione insieme. Sarebbe un incubo commettere qualcosa e aspettare che qualcuno aggiusti il test unitario. Ciò significherebbe che i test unitari falliscono sempre. Immagina ... tu impegni il codice, qualcun altro fa una svn e le prove falliscono. In questo modo anche l'integrazione continua è impossibile.
• I test unitari fanno molto più che controllare se il codice funziona. In TDD, ad esempio, i test unitari ci aiutano a ottenere un design migliore.

Un'altra cosa da sottolineare. Solo perché scrivi test in un framework di test unitario, non significa che stiano scrivendo test unitari. Il nostro team ad esempio utilizza il framework Junit insieme a Selenium per scrivere test di accettazione. Sarebbe OK per il QA scrivere questi test.

Gli sviluppatori dovrebbero essere quelli che scrivono i test delle unità, poiché sono quelli che hanno più familiarità con il codice. I test unitari devono essere scritti prima, durante o subito dopo la scrittura del codice. Di conseguenza, gli sviluppatori dovrebbero anche creare mock (e la maggior parte delle persone usa un framework al giorno d'oggi, quindi non è un'attività che richiede molto tempo).

Il QA potrebbe essere responsabile per diversi tipi di duplicati di test coinvolti in test di sistema più ampi. Ad esempio, se un'applicazione dipende da dispositivi hardware, potrebbe aiutare con il software di simulazione. Tuttavia, non ho notato personalmente che il QA è coinvolto nelle attività di programmazione. Il QA può creare test di integrazione, ma di solito dipendono sempre dagli sviluppatori per scrivere fixture di test per i quali possano collegarsi.