Dovrei dedicare del tempo a testare le unità? [chiuso]

5

La società per cui lavoravo prima di avere test unitari automatizzati per testare il nostro lavoro. Tuttavia, gli standard e l'architettura di codifica non erano molto importanti per i test. Ovviamente hai dovuto indentare il codice correttamente e mettere le parentesi graffe dove dovresti mettere le tue parentesi graffe, ma nessuno farebbe la raccolta nit attraverso il tuo codice di test. Questo mi sembrava ragionevole in quanto i test venivano solitamente cambiati di frequente e l'idea era di scrivere rapidamente un test e poi iniziare seriamente a scrivere il codice.

La nuova azienda ha appena imparato il collaudo delle unità del nostro lavoro, ma si aspetta che tu spenda tempo per assicurarti che il codice del test sia bello e ben concepito come il codice che sta testando. Personalmente ritengo che sia una perdita di tempo poiché i test sono interni e mentre il codice di test dovrebbe essere accurato, non deve essere progettato alla perfezione come il codice che esce dalla porta del cliente.

Ho sbagliato nella mia convinzione? Qual è la cosa giusta da fare qui colleghi programmatori?

La frequenza di quanto spesso i nostri programmatori devono modificare / estendere / riutilizzare i test di unità esistenti varia, alcuni più spesso e altri meno spesso. Stiamo usando Python Django e la maggior parte dell'architettura di test è integrata e la maggior parte dei test sono semplici funzioni. Necessario molto meno setup / teardown.

    
posta Ali 16.01.2013 - 13:16
fonte

7 risposte

17

Il motivo per cui crei un bel codice è perché rende il codice più facile da mantenere in una fase successiva.

Quando i requisiti del software cambiano durante lo sviluppo, tutti i test unitari devono essere modificati per verificare la correttezza in base ai nuovi requisiti anziché ai vecchi. Per rendere ciò possibile, i test unitari devono essere mantenibili.

Inoltre, quando uno dei test fallisce, il programmatore che ha interrotto il test vorrà sicuramente sapere perché ha fallito. Per farlo, ha bisogno di guardare i test e scoprire cosa stanno effettivamente testando. Ciò sarà considerevolmente più semplice quando il codice di test è di facile comprensione.

Quindi sì, dovresti mirare a uno standard di alta quailtiy quando scrivi il codice di test delle unità.

    
risposta data 16.01.2013 - 13:36
fonte
6

Alcune parti di uno standard di codifica dovrebbero applicarsi allo stesso modo al codice di produzione e al test unitario. In particolare, le convenzioni di denominazione, il posizionamento dei controventi e lo stile di indentazione.
Il motivo è che dà a tutto il codice un aspetto coerente.

Alcune parti si applicano ai test unitari, ma non si tende mai a violarli comunque. Pensa a cose come la complessità delle funzioni.

Alcune parti, vorrei ignorare per i test unitari, come i requisiti per lo spostamento di codice simile in funzioni. Per me, una certa quantità di copia-incolla è accettabile nei test unitari, ma meno nel codice di produzione.

Quindi, alla fine, sì, gli standard di codifica si applicano principalmente anche ai test unitari.

    
risposta data 16.01.2013 - 13:32
fonte
4

Nella mia esperienza, i bravi programmatori sono perfezionisti. I bravi programmatori scrivono tutti i loro programmi nello stesso modo coerente. Mantengono lo stesso stile di codifica in modo coerente ed evitano le stesse cattive pratiche, indipendentemente dal tipo di programma che stanno facendo.

I programmatori potenzialmente cattivi fanno il contrario. Vanno sempre alla ricerca di scuse per rendere i programmi sciatti. Alcuni segnali di avvertimento sono commenti come "nessuno leggerà questo codice tranne me", "questo codice non verrà mai riutilizzato", "Lo sistemerò più tardi", "L'ho offuscato per evitare digitazioni extra" ecc. Tali programmatori tendono a scrivere codice sciatto non solo nel quick & test sporchi, ma anche dove è più importante.

Considera questo: quanto è probabile che riutilizzerai il codice di un vecchio test quando ne stai scrivendo uno nuovo? Si spera che la risposta sia "abbastanza probabile".

Quindi, ovviamente, potrebbe non essere necessario produrre la stessa quantità di "attività generali" quando si codificano alcuni quick & caso sporco. Il codice sorgente e l'altra documentazione non devono essere dettagliati, i controlli di qualità come la revisione manuale del codice, l'analisi statica, ecc. Non devono essere rigorosi, la gestione della versione e la pubblicazione non devono essere necessariamente formali. Ma non ci sono ovvi motivi per cui il codice sorgente di per sé dovrebbe essere più sciatto

    
risposta data 16.01.2013 - 15:29
fonte
2

Il reclamo secondo cui i test non devono essere "[come] ben pensato come il codice che sta testando" non è valido.

Se stai usando i test per definire il comportamento previsto del codice, se le tue aspettative sono create senza rigore, il codice che soddisfa tali aspettative sarà sciatto e mal concepito. Potrebbe anche non riuscire a coprire tutti i casi importanti o cuocere in ipotesi pensate male.

Qualcuno dovrebbe essere in grado di venire al test dell'unità e vedere cosa sta dicendo il test sul comportamento dell'unità in prova, quali sono i vincoli su quel comportamento e come si prevede che l'unità sarà utilizzata. Aggiungi qualsiasi architettura e documentazione per il test è necessario per raggiungere questo obiettivo.

    
risposta data 16.01.2013 - 14:38
fonte
2

Should I spend time prettifying unit tests?

Se la stimolazione significa rendere il test unitario più coerente e più facile da capire allora sì.

Poiché non ho scritto un libro o intervistato molte persone, posso solo passare la mia esperienza personale in questa materia. Recentemente ho trascorso una settimana su un progetto F # facendo diverse centinaia test di unità coerente, più facile da leggere e più completo. Nel processo ho imparato alcune cose e ho sviluppato un filosofia .

  1. Nel rendere coerente il test unitario, ho iniziato a vedere casi di test che dovevano essere aggiunti per rendere completo il test di una funzione. Poiché il test unitario era coerente, era facile individuare i casi che dovevano essere aggiunti. Fondamentalmente ho provato a spostare i parametri e il risultato di una funzione in un elemento dell'array con tutti i casi di test per una funzione in un array uno dopo il successivo. Ha fatto sì che vedere i pattern di questo input rendesse questa uscita facile perché bastava guardare l'input e l'output, non tutto il sovraccarico necessario per un test case. Poi sono passati i meccanismi del test case estraendo i parametri e il risultato e passandoli attraverso la funzione test.

Ad esempio:

let private butLastValues : (int list * int list)[] = [| 
(
    // idx 0
    // lib.butLast.01
    // System.Exception - butlast
    [],
    [] // Dummy value used as place holder
);
(
    // idx 1
    // lib.butLast.02
    [1],
    []
);
(
    // idx 2
    // lib.butLast.03
    [1; 2],
    [1]
);
(
    // idx 3
    // lib.butLast.04
    [1; 2; 3],
    [1; 2]
);
|]

[<TestCase(0, TestName = "lib.butLast.01",     ExpectedException=typeof<System.Exception>, ExpectedMessage="butlast")>]
[<TestCase(1, TestName = "lib.butLast.02")>]
[<TestCase(2, TestName = "lib.butLast.03")>]
[<TestCase(3, TestName = "lib.butLast.04")>]

[<Test>]
let ''List butlast'' idx = 
    let (list, _) = butLastValues.[idx]
    let (_, result) = butLastValues.[idx]
    butlast list
    |> should equal result
  1. Facendo in modo che il test unitario fosse più facile da leggere, divenne ovvio che erano abbastanza buoni da essere utilizzati per l'apprendimento perché la completezza del test unitario per una funzione divenne migliore di quella della documentazione; è stato un vero esempio di lavoro che non solo ha dimostrato un caso ma ha anche mostrato quale sarebbe stato il risultato, che si tratti di un risultato valido, di un'eccezione o di un mancato completamento.

  2. Poiché il nostro progetto era una traduzione del codice OCaml dal "Manuale di Logica Pratica e Automated Reasoning " di John Harrison, abbiamo creato sia una versione di traduzione diretta che una versione ottimizzata. Dopo aver completato il test, è stato più semplice testare ulteriormente il codice ottimizzato e il codice normale utilizzando lo stesso test case.

Quindi, passando il tempo a lavorare con il test dell'unità a mano e in dettaglio, ho imparato di più su come funzionava il codice piuttosto che leggendo il codice. Ho iniziato a vedere i modelli nei dati di test che non sarei stato visto nel codice e ho sfruttato questo per saperne di più su come funzionava il codice.

Se visualizzi il test unitario come qualcosa che dovrebbe essere creato e lasciato in una scatola solo per essere utilizzato da strumenti automatici, penso che manchi qualcosa di significativo.

    
risposta data 16.01.2013 - 14:28
fonte
1

Dovresti sforzarti di costruire un software di qualità. I test unitari sono software.

    
risposta data 16.01.2013 - 13:29
fonte
0

Se i test dell'unità sono eseguiti in modo impeccabile, ma il codice principale non viene eseguito, il progetto è un fallimento. Se il codice principale funziona in modo impeccabile, ma i test unitari no, allora il progetto è un successo (anche se con una metodologia imperfetta).

Se stai facendo qualcosa che spende una quantità significativa di tempo e solo i risultati nei test unitari sono più belli, stai perdendo tempo.

    
risposta data 16.01.2013 - 16:10
fonte

Leggi altre domande sui tag