In che modo sono correlati la progettazione per contratto e il test basato sulle proprietà (QuickCheck)?

Question

In che modo sono correlati la progettazione per contratto e il test basato sulle proprietà (QuickCheck)?

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

4

È la loro unica somiglianza il fatto che siano not xUnit (o più precisamente, non basati sull'enumerazione di casi di test specifici), o è più profondo di così?

I test basati su proprietà (usando QuickCheck, ScalaCheck, ecc.) sembrano adatti per uno stile di programmazione funzionale in cui vengono evitati gli effetti collaterali. D'altra parte, Design by Contract (come implementato in Eiffel) è più adatto ai linguaggi OOP: puoi esprimere post-condizioni sugli effetti dei metodi, non solo sui loro valori di ritorno.

Ma entrambi implicano test affermazioni che sono vere in generale (piuttosto che asserzioni che dovrebbero essere vere per un caso di test specifico). Entrambi possono essere testati utilizzando input generati casualmente (con QuickCheck questo è il modo solo , mentre con Eiffel credo che sia una funzionalità opzionale dello strumento AutoTest).

Esiste un termine generico per comprendere entrambi gli approcci? O sto immaginando una relazione che in realtà non esiste.

testing xunit design-by-contract

posta Todd Owen 29.06.2013 - 03:47

fonte

2 risposte

2

La relazione è che la combinazione di design per contratto e metodi di test sta tentando di sostituire una prova di correttezza, che sarebbe l'obiettivo finale, se fosse fattibile. Le pre-condizioni e le post-condizioni (per i valori di ritorno) sono utili anche in metodi senza effetti collaterali, in quanto limitano i domini di input e gli intervalli di output.

risposta data 01.07.2013 - 19:04

fonte

Leggi altre domande sui tag testing xunit design-by-contract

Che cosa è una buona regola per nominare le tabelle dei collegamenti? Ricostruzione di un albero dalle informazioni di profondità

score 1 · Accepted Answer

Forse una relazione sta nel concetto di Oracle descritto da Bertrand Meyer, autore di Eiffel, in " Sette principi del test del software ".

A test run is only useful if you can unambiguously determine whether it passed. The criterion is called a test oracle. If you have a few dozen or perhaps a few hundred tests, you might afford to examine the results individually, but this does not scale up. The task cries for automation.

Principle 4: Applying oracle Determining success or failure of tests must be an automatic process.

This statement of the principle leaves open the form of oracles. Often, oracles are specified separately. In research such as ours, they are built in, as the target software already includes contracts that the tests use as oracles.

Principle 4 (variant): Contracts as oracles Oracles should be part of the program text, as contracts. Determining test success or failure should be an automatic process consisting of monitoring contract satisfaction during execution.

Basandoci su questo, immagino che potremmo dire QuickCheck e Eiffel's Auto Test utilizzano sia test oracoli automatici ma diversi moduli oracle , il primo è esterno al programma di produzione (proprietà espresse in separato test suite) e il secondo, integrato nel programma di produzione (contratti).
Da un punto di vista storico, possiamo supporre che QuickCheck (pubblicato per la prima volta nel 1999) e precedenti lavori sui test basati sulle proprietà risalenti agli anni '90 abbiano ispirato l'AutoTest di Eiffel (apparso nel 2008), sebbene io non ho trovato alcuna prova certa di ciò nelle carte o nelle interviste di Bertrand Meyer.