"Le funzionalità software che non possono essere dimostrate con test automatici semplicemente non esistono" - È un'affermazione troppo estrema?

Ogni volta che sento un'affermazione estrema come questa, considero il problema che stanno affrontando e come si propongono di risolverlo. Successivamente, utilizzo il mio cervello per giudicare quando l'affermazione non si applica.

12 anni fa, il test unitario (almeno come lo conosciamo oggi) era un fenomeno relativamente sconosciuto tranne che per i magi che lo promuovevano. Kent Beck era uno di quei magi. Ogni volta che vuoi convincere qualcuno a provare qualcosa di nuovo, sembra che un'iperbole sia un requisito.

L' intento della dichiarazione era che se testi tutti gli aspetti interni del tuo codice come il modello e le parti del controller della tua app, l'applicazione è funzionalmente corretta. Ho imparato rapidamente che l'unico modo per testare l'interazione dell'utente è con gli utenti effettivi (gasp, cough, choke).

Detto questo, non buttare il bambino con l'acqua del bagno, ma usa il buon senso quando senti affermazioni del genere.

Software features that can't be demonstrated by automated tests simply don't exist

È una delle cose più arroganti e più stupide che abbia mai sentito.

Dimentica quell'assurdità. (Suppongo che l'espressione art meriti lo stesso tipo di risposta)

Con quali test automatici puoi misurare l'esperienza utente? Ed è una delle caratteristiche chiave dei moderni prodotti software. Intangibile, ti darò questo, ma comunque cruciale per il successo del mercato. Non è possibile scrivere un test macchina per questo, ma il cervello umano metterà alla prova questa caratteristica in pochi minuti con un test penetrante, crudele e indulgente.

He wrote that 12 years ago.

Questo non esisteva in quel momento, o era molto limitato.

Quando ho letto quello che ho scritto 12 anni fa, voglio nascondermi sotto il mio letto e piangere.

Software features that can't be demonstrated by automated tests simply don't exist

È una delle cose più utili e utili che abbia mai sentito.

Sapendo che non puoi misurare l'esperienza utente, devi comunque creare un software che funzioni. Se il software funziona o non funziona è indipendente dal suo aspetto.

Il software di bell'aspetto non può fare nulla.

Un software dall'aspetto cattivo può risolvere completamente un problema in modo elegante ed efficace.

I mean, I can't demonstrate ... the screen pixel is correct in automated tests. So my features don't exist?

"le mie funzionalità non esistono" sta prendendo il commento troppo lontano dal contesto.

Hai due cose non correlate.

1. Funziona.

2. Sembra corretto.

Uno deve essere testato. Se non riesci a testarlo, allora non esiste.

L'altro deve essere sperimentato. Tieni presente che puoi apportare modifiche all'interfaccia utente che gli utenti non possono provare. Neanche loro esistono.

Gli utenti daltonici, ad esempio, non possono dire che hai fissato lo sfondo "rosso" come un "rosso" diverso. Se hai scelto un colore che un utente non può vedere, il colore non esiste.

Dovresti leggere questo articolo, in cui Joel Spolsky lacera questa nozione e spiega che portarlo alla sua conclusione logica è fondamentalmente "l'equivalente software di una macchina per moto perpetua".

E i processi casuali complessi? È possibile verificare che l'oggetto dati risultante sia legale per le regole in vigore ma non è possibile renderlo stabile rispetto alle modifiche al codice. Il derisione del generatore casuale non è di aiuto se si modifica la sequenza di chiamate al generatore.

Una cosa del genere è improbabile nel mondo degli affari ma i mondi di gioco generati casualmente sono un'altra cosa.