Drivers

[ZanSara]

Dando un'occhiata al lavoro degli altri, ho notato che "in teoria" se utilizziamo un approccio bottom-up per l'integrazione, e' probabile che servano dei driver ("falsi chiamanti" per innescare i processi da testare).

Dovrebbero servire durante i test di integrazione dei pezzettini interni dei componenti.

Non ho ancora riletto bene quella parte (ora la rileggo): nel nostro caso servono?

[siscia]

I processi da testare saranno innesscati dai test, no?

[siscia]

Non sono certo di aver capito cosa intendi...

[ZanSara]

Aspetta ricontrollo le slide e/o metto in crisi anche il lavoro di Gian 😅

[ZanSara]

Diciamo che che cosa siano e' chiaro, ma a cosa diavolo servano no. Non ho trovato ancora nessuno, neanche su internet, che voglia dirmi a che servano i drivers, anche se tutti sanno cosa sono e concordano che vengano utilizzati negli integration test.

D'altra parte, in fondo a pagina 12 del documento di esempio ne parla e sembra che driver = codice del test. In pratica bisogna specificare che il test di integrazione bottom-up esige del codice esterno (il driver), perche' in effetti in modalita' top-down non serve un "codice di test", ma solo molti stub (o almeno cosi mi pare di capire).

Non so se sono riuscita a spiegarmi...

(per "documento di esempio" intendo quello che abbiamo nella cartella DOC della repo)

[siscia]

No, non ci sei riuscita...

Se pensi vada aggiunto qualcosa aggiungi pure (fai prima che spiegarmelo)

Ad occhio e croce è abbastanza una cazzata da aggiungere...

----- Messaggio originale ----- Da: "Sara Zan" notifications@github.com Inviato: ‎13/‎01/‎2017 15:54 A: "siscia/INGSW2" INGSW2@noreply.github.com Cc: "Mosciatti S." sisciaprivate@gmail.com; "Comment" comment@noreply.github.com Oggetto: Re: [siscia/INGSW2] Drivers (#65)

Diciamo che che cosa siano e' chiaro, ma a cosa diavolo servano no. Non ho trovato ancora nessuno, neanche su internet, che voglia dirmi a che servano i drivers, anche se tutti sanno cosa sono e concordano che vengano utilizzati negli integration test. D'altra parte, in fondo a pagina 12 del documento di esempio ne parla e sembra che driver = codice del test. In pratica bisogna specificare che il test di integrazione bottom-up esige del codice esterno (il driver), perche' in effetti in modalita' top-down non serve un "codice di test", ma solo molti stub (o almeno cosi mi pare di capire). Non so se sono riuscita a spiegarmi... — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[ZanSara]

Se non riesco a spiegartelo, evidentemente anche io non ho chiaro come devo scriverlo e quindi e' meglio che non scriva nulla :sweat_smile:

Ultimo tentativo. Guarda questo (dal documento di test):

Secondo me "Client Driver" significa "pezzo di codice che chiama il componente da testare proprio come farebbe Client Driver se fosse implementato". Secondo me bisognerebbe specificare che il codice del test di integrazione sta emulando la chiamata effettuata da un altro componente, e specificare quale. Esempio pratico:

Qui, per esempio, il driver da specificare (credo) sia la GUI della app pubblica: e' lei che effettuerebbe la chiamata a POSITION/Car che ci permette di testare l'integrazione con GEOLOCATION. Quindi qui si potrebbe aggiungere qualcosa del tipo:

Requirements: PublicGUI driver.

Se tutto questo ha qualche senso, provo a trovare un driver per i test (provo perche' non mi e' evidente per ogni test quale sia il chiamante). Se invece non ha senso lascio perdere.

[siscia]

Quale codice chiama cosa è gia stato specificato nel documento di design.

Quello che facciamo noi è semplicemente dire, questi sono i test che, se i componenti sono ben integrati, devono funzionare.

Onestalmente non ho ben capito nè l'utilità (il che sarebbe il meno) nè bene cosa sono questi driver.

Cioè, il test esegue del codice e conferma che il risultato di questo codie sia quello che ci si aspetta, roba molto semplice...

[ZanSara]

Ok si in effetti credo sia un po' troppo contorta come cosa... meglio lasciar stare 😁