Posso evitare ulteriori errori se utilizzo diversi paradigmi per l'implementazione e le specifiche / test?

Questo non è completamente correlato, ma se si includono linguaggi di specifiche formali, si hanno vantaggi con l'annotazione del codice con invarianti formali e contratti.

Vedi ad esempio il manuale di riferimento ACSL , per C. Lo stesso vale per Ada che consente forall espressioni che non fanno parte della lingua, ma disponibili per le specifiche: link . Inoltre, potresti dare un'occhiata a ACL2 .

Quando si tratta di test, si consiglia di consultare Basato su modelli Test : definisci un modello che è utile solo per i test.

Spesso è più facile descrivere il test in modo funzionale, in modo chiaro, trasmette cosa dovrebbe fare l'implementazione, invece di come .

Penso che quello che vuoi sia un certo livello di formalismo, vedi Metodi formali . Questo è l'unico modo garantito per ottenere meno errori utilizzando paradigmi diversi perché l'uso di qualcosa di diverso ha anche il potenziale di dare diversi errori (anche le correzioni producono errori).

L'implementazione a livello più vicino alla matematica darà la possibilità di avere un certo livello di prova matematica, il che significa che non avrai alcun difetto e che potenzialmente eliminerai la necessità di test.

Questo link Da HOL a Haskell e Fondamentali software dovrebbero illustrare le idee sull'uso delle specifiche di sviluppo nel dimostratore di teoremi e quindi tradurle in linguaggio di programmazione. Un articolo parla dell'utilizzo di Isabelle / HOL e haskell, l'altro riguarda l'uso di Coq, che quindi puoi tradurre in scala usando alcuni strumenti.

Perché ci vuole più tempo per farlo formalmente, solo una piccola quantità di codice viene sviluppata in questo modo.

È mia opinione come una persona di controllo qualità che uno non ha realmente bisogno di paradigmi di test diversi. Molti non saranno d'accordo con questa affermazione, ma c'è solo un metodo necessario che sta semplicemente testando tutti i casi limite conosciuti di qualunque esso sia. La teoria è semplicemente Min, Min-1, Min + 1, Max, Max-1 e Max + 1, Null e o Empty String. Se tutti questi bordi sono stati testati, hai un codice antiproiettile.

Le persone diranno sciocchezze e usano termini fantasi come end-to-end, scatola nera, scatola bianca, scatola grigia, test unitario, test di accettazione degli utenti, test unitario, integrazione, test dei componenti e del sistema, parleranno di casualità , approcci statistici. ecc. Tutto quanto sopra si riduce ai casi Edge come metodo da utilizzare. I test dei casi limite possono essere eseguiti manualmente, automatizzati ecc.

Infine gli studi mostrano che il 70% di tutti i bug sono stati introdotti prima che lo sviluppatore consegnasse il codice al QA. Cosa significa questo? Significa che il massimo sforzo per l'automazione è Unit Test! Considerando questo, il 90% di tutti gli sviluppatori afferma che "Unit Testing non è integrato nel mio programma" ... Il risultato è che il codice non a prova di proiettile viene continuamente consegnato al QA, ma il QA può prendere solo il 20-50 % di tutti i bug in quanto non possono vedere il codice di solito ...

Scrivere casi di test nella lingua utilizzata dagli sviluppatori è buono perché ora gli sviluppatori possono contribuire e mantenere la libreria Test unità. I componenti di QA dovrebbero essere integrati con gli sviluppatori e scrivere test mentre il codice viene creato. Gli stub di test possono essere scritti solo da una specifica e rendere il test quasi pronto per quando il codice è presente.

È vero che gli sviluppatori semplicemente non hanno il tempo giusto per sviluppare buoni Test unitari dati gli orari veloci di oggi.