Gestione delle attività di test delle unità ripetitive [duplicate]

Question

Gestione delle attività di test delle unità ripetitive [duplicate]

#1 da (2 voti)
#2 da (-2 voti)

0

Questo problema è sorto durante la scrittura di una semplice classe vettoriale 3D.

La classe conteneva metodi (Java, quindi nessun sovraccarico dell'operatore) per addizione, sottrazione, moltiplicazione e divisione. Questi metodi hanno eseguito questa operazione tra l'istanza in cui sono stati richiamati e un altro vettore o singolo valore.

Quando si trattava di scrivere i test unitari, non ero sicuro di come avrei dovuto affrontare questo test.

Le tre opzioni che ho potuto ottenere erano le seguenti:

Prova i metodi Add , Sub , Mul e Div separatamente (due per ciascuno, vettore e valore), con valori diversi per ogni
Testare i metodi separatamente con gli stessi valori ogni volta, ma con risultati attesi diversi
Non testare i metodi in quanto sono molto semplici (non adatti alla copertura)

Quale metodo sarebbe più desiderabile in questa situazione? Questo vale anche per qualsiasi altro scenario in cui un'attività è molto ripetitiva.

language-agnostic unit-testing

posta The6P4C 03.10.2014 - 14:20

fonte

2 risposte

-2

In realtà non lo vedo come un problema di domande e risposte, ma completamente soggettivo. La risposta "corretta" è quella che ottiene il set di test più completo e accurato.

La noia è l'ostacolo più decisivo per il tuo "problema": ad una estremità dello spettro si insinuano gli errori perché sei così annoiato dalla ripetizione che i tuoi occhi si velano e perdono l'attenzione ai dettagli.

All'estremità opposta si elabora un'elaborata struttura di test automatizzata che ti tiene in difficoltà, ma è inevitabilmente soggetto a errori dovuti a problemi imprevisti (es. bug) e problemi di manutenzione esoterica. Troppo lontano da questa parte e hai bisogno di test per il tuo codice di test.

Come individui il nostro percorso dei minimi errori varierà. Basta sapere che ce n'è uno e traccia la linea che ritieni sia più adatta a te.

risposta data 03.10.2014 - 15:15

fonte

Leggi altre domande sui tag language-agnostic unit-testing

Questo diagramma fornisce una buona rappresentazione del pattern MVVM? API REST + Confini "Micrososervices"

score 2 · Accepted Answer

L'unica scelta che è chiaramente sbagliata è "Non testare i metodi in quanto sono molto semplici."

Non testare è un test negativo, indipendentemente da quanto siano semplici i metodi.

Alcuni sviluppatori preferiscono test unitari di ricambio, in cui "solo una cosa può fallire". Di conseguenza, anche i metodi semplici potrebbero meritare molte funzioni / metodi di test individuali.

Per ridurre il boilerplate, l'eccesso di "testing noise" e la noia, la mia preferenza sono test più lunghi che danno a ciascun metodo base una buona corsa per il loro denaro (almeno includendo alcuni casi semplici e alcune gabbie).

Vorrei utilizzare un ibrido tra scelta 2 e scelta 1: utilizzare almeno alcuni degli stessi valori nei test dei diversi metodi Add , Sub , ecc., con risultati attesi diversi (scelta 2). Gli input comuni semplificheranno la comprensione non solo del codice di test, ma anche dello scopo del test - un elemento importante poiché, nel tempo, l'ideale è estendere i test per essere più completi, più ricchi e coprire più casi.

Ma alcuni metodi come Div e Mul elemosinano alcuni test che sono diversi da quelli per le operazioni additive (ad esempio test divide per zero). Quindi, per semplicità, inizia con la scelta 2, quindi per esercitare correttamente gli utili casi limite, un pizzico di scelta 1 (aggiungendo input diversi).