Testare il codice a livello di programmazione: dal programmatore o da qualcun altro?

Question

Quindi ecco la situazione: una citazione del mio capo: [...] Dobbiamo concentrarci sulla programmazione. [...] Alla fine della giornata voglio scrivere un buon software e non essere impantanato con i test . " Questo è detto dopo che abbiamo avuto 3 mesi di un elenco scoraggiante di bug e recentemente designare un non programmamista per scrivere test web con framework di selenio.

Il mio capo è molto timido nel test delle unità (non riesce a vedere il beneficio di costo quando rallenta gli sviluppatori). Quali sono le tue opinioni là fuori su test web e test programmatici in generale? Dovrebbero essere scritti dal (o a) programmatore o importa? Il mio pensiero era che parte della scrittura di un buon software sta scrivendo test? È un tipo di ragazzo di Microsoft avorio-torre, e quindi qualsiasi risorsa là fuori che è stata pubblicata da Microsoft (o buoni articoli in generale) a favore dei test in base alla progettazione sarebbe utile.

Answer 1

Ecco cosa ho fatto.

1. Ho scritto comunque i test.

2. Ho scritto il codice dopo aver scritto i test.

3. Il codice era solido al rock e (principalmente) senza bug (ai limiti delle mie capacità.)

Non ho mai detto a nessuno che stavo facendo TDD. A meno che non lo chiedano.

Si scopre che il TDD è in realtà più veloce che scherzare cercando di progettare qualcosa, codificarlo e sperare che funzioni.

Alcune cose includono un passaggio in più 0: un "picco tecnologico" per vedere come funzionano le cose. Questo è seguito da uno sviluppo di test per esercitare il vero software reale non ancora scritto.

Sono un po 'in ritardo quando si tratta di iniziare il design. Dal momento che il mio design è "Test di progettazione e scrittura per quel design", mentre alcune altre persone sono "graffiare con alcune idee intelligenti ma nessuna vera prova". Alcune persone possono progettare bene sulla carta. Non posso. Ma posso progettare test.

Sono generalmente abbastanza lontano quando si tratta di finire il codice. Da quando - quando ho finito di codificare - tutti i test passano.

Answer 2

Codice Complete è un libro che fa parte della collezione Microsoft. Contiene consigli che sostengono la revisione tra pari e la spazzolatura dei test unitari come concetto. Non va troppo lontano nei dettagli con i test unitari, ma può riscaldarlo all'idea e puoi esplorare ulteriormente l'argomento da lì.

Alla fine hai bisogno di qualcuno che sia un programmatore direttamente coinvolto nell'automazione dei test ... Voglio dire, per definizione.

I test unitari sono scritti in modo più efficace dalle persone che hanno più familiarità con i sottosistemi per cui sono scritti, quando è scelto qualcun altro per scrivere test unitari, ci vuole tempo per accelerare e possono perdere l'intenzione non documentata o chiara nel codice che potrebbe causare una copertura peggiore. Il rovescio della medaglia, il proprietario del sottosistema può essere cieco anche a determinate carenze (ma questo è ciò a cui sono le recensioni del codice peer!)

---

Il resto è davvero solo una discussione inattiva sull'etica, ma è importante da considerare.

Ad alcune persone piace provare a "sgattaiolare merda" alla build quando il management prende decisioni sciocche. Questo mi rende non solo inquieto, ma anche un po 'diffidente nei confronti di quei programmatori. Capisco la motivazione, penso che siamo stati tutti lì, ma alla fine dovresti educare piuttosto che partecipare al sotterfugio.

La direzione svolge un ruolo importante nella programmazione e si basano su di te sia per stime accurate sia per una comprensione generale del lavoro svolto. Se le tue stime per spazzare il lavoro extra sotto il tappeto è davvero una buona cosa? Quella che era una semplice bugia diventa questa elaborata bufala che stai giocando sulle persone direttamente coinvolte nell'aiutare i tuoi progressi nella carriera.

Ciò che è stato un problema con il processo e la stima per il lavoro legittimo è diventato un problema etico appiccicoso.

Consiglio vivamente di seguire il tuo approccio pianificato di convincere il tuo manager a vedere il tuo punto di vista tramite ragione, logica e appello al suo amore per Microsoft. ;)

A lungo termine se ti ritrovi a combattere costantemente la gestione sulle decisioni sul processo di programmazione (che in realtà non è il loro lavoro su cui prendere le decisioni) sarebbe probabilmente meglio lucidare che riprendere e trovare un lavoro migliore.

Parte del lavoro di un programmatore è educare le persone coinvolte che hanno meno competenze. Spiegare che al tuo manager può aiutare a scomporre alcune delle barriere intellettuali che ha sull'argomento e ammorbidirlo per accettare i tuoi consigli sulla questione.

Answer 3

Vado per il mondo che per qualcosa di "fatto" deve essere stato verificato da almeno due persone. Non hai sempre bisogno di un tester software nel team se tutti nel team credono che la qualità del software sia il lavoro di tutti.

Se vuoi che sia altamente efficiente, lo sviluppatore che scrive il codice dovrebbe scrivere i test e qualcuno li esamina con il codice di produzione. Se vuoi essere altamente efficace, abbina qualcuno e scrivono i test mentre scrivi il codice in un "TDD accoppiato".

Ricorda al manager che il costo dei bug cresce sostono in seguito.

Answer 4

Capisco da dove viene il tuo capo. Dopotutto, i programmatori dovrebbero essere in grado di sfornare il codice che "funziona". Tuttavia, test volere accade, non importa, sia esso test unitario, test di integrazione in azienda o dopo l'installazione del cliente. Gli errori in ciascuna di queste fasi hanno costi e conseguenze diversi, sebbene ...

Answer 5

Sentirai spesso che è una buona idea rendere le altre persone testare il tuo codice perché potrebbero interpretare le specifiche in modo diverso. Tuttavia, il vantaggio di scrivere i test per il tuo codice è che sai dove può essere difettoso.

Un approccio efficiente potrebbe essere una miscela di entrambi: il programmatore che scrive i suoi test unitari, si concentra su casi d'angolo e qualcun altro che fa alcuni test funzionali, concentrandosi sulle specifiche di livello superiore.

Answer 6

Non tutti i test sono creati uguali, andiamo oltre alcuni:

• Test unitari / TDD. È difficile discutere contro di esso, specialmente perché è il contrario di "non può vedere il beneficio in termini di costi quando rallenta gli sviluppatori", è più veloce. S. Lott esamina i dettagli.
• Test di integrazione focalizzati. Come sopra, è più veloce. Non è necessario eseguire una serie di passaggi tramite l'app completamente integrata, per scoprire se quel livello molto sottile di codice di integrazione che hai appena scritto funziona. È peggio se si considera che si ripete tutte le volte che devi andare lì, e ancora di più quando diventa erroneamente accoppiato a processi diversi.
• Test del sistema completo. Con quanto sopra in posizione, vuoi solo sapere se tutti i pezzi sono stati agganciati correttamente e se l'interfaccia utente funziona come previsto. Per la prima è necessaria una piccola quantità di test molto rapidamente scritti; Confrontalo con quante volte le persone si superano manualmente (incluso te stesso) e hai un vincitore :). Per i successivi ci sono alcune cose che sono difficili da catturare con test automatizzati, quindi non focalizzi l'automazione su quelli.
• Test esplorativi. Questi dovrebbero ancora essere fatti, si spera che sia stato creato abbastanza prima che la funzione sia costruita per evitare di dover fare cambiamenti extra a questo punto.

Ora, il QA di solito presenta scenari aggiuntivi. Questo è buono, ma è meglio quando è incluso in modo collaborativo nei test automatizzati.

Un vero problema può essere l'attuale capacità di squadra. Il test unitario è più difficile più accoppiato è il codice, di solito è il peggio con il codice esistente senza test unitari, ma inizialmente rende anche più difficile andare avanti per uno sviluppatore che non sa bene come progettare il codice vagamente accoppiato/alto Codice di coesione. Deve essere fatto, ma sii consapevole di questo poiché il costo andrà da qualche parte (per i membri del team o la società).

Answer 7

Per creare una buona suite di test, ci vuole un po 'di sforzo; Questo richiederà più tempo del previsto.

A questo proposito, il tuo capo ha ragione.

Tuttavia, se si prevede di estendere il tuo prodotto (Aggiungi funzionalità) o sito Web (Aggiungi pagine e codice JavaScript), tuttavia, è necessario creare la suite comunque in un secondo momento.

Answer 8

Potresti sottolinearlo Test unitari è stato integrato nel framework .NET da VS2005.