TDD Test Driven Development

TDD - Perchè NO
Quali sono le principali difﬁcoltà e le principali insidie
nell’approccio TDD


TDD - Punti deboli e criticità

- Il codice dei test è codice extra che va mantenuto
- Scrivere i test richiede tempo
- Serve esperienza per capire cosa testare e cosa no
- Per essere realmente efﬁcace tutto il team dovrebbe abbracciare il TDD


TDD - Punti deboli e criticità
Usare TDD è molto difﬁcile
in situazioni come:

- Lo sviluppo delle interfacce utente
- Lo sviluppo di software che dipendono strettamente da
un database


Ne vale la pena ?


TDD - Perchè SI


TDD - Vantaggi e obiettivi
Meno fatica
a parità di risultati


TDD - Vantaggi e obiettivi
- Produttività aumentata
- Conﬁdenza nel codice aumentata
- BugFix più semplice
- Documentazione tecnica implicita
- Migliore architettura del software
- Rifattorizzazione più semplice


Ne vale la pena


Che cosa è TDD

di cosa stiamo parlando esattamente ?


TDD is about
DESIGN

TDD is about
DELIVERING BUSINESS VALUE

TDD is about
CLEAN CODE THAT WORK

TDD come
Sviluppare applicazioni web con TDD


TDD Come


TDD - Come

- Basato sui cicli ripetuti di RED - GREEN - REFACTOR
- I test si implementano PRIMA del codice
- Inizia sempre con un test RED
- Finisce sempre con un test GREEN
- Isola e spezzetta i problemi in unità minime


TDD - Da fare SEMPRE

- Scrivere i test PRIMA del codice
- Mantenere una TODO list per i test
- Eseguire tutti i test ogni volta e non solo quelli collegati alla modiﬁca fatta
- Il lavoro è completo quando tutti i test nella TODO list sono OK


TDD - Best Practice

- Iniziare scrivendo i test per le funzionalità più semplici
- Eseguire i test subito dopo una modiﬁca al codice
- Se la scrittura di un test richiede troppo tempo spezzare il problema e suddividere in
più test


TDD - Da non fare MAI

- Scrivere test per metodi banali (getter e setter)
- Committare codice con test che FALLISCONO
- Implementare nuove funzionalità con test che FALLISCONO
- Iniziare una rifattorizzazione con test che FALLISCONO
- Creare dipendenze tra i vari test


Development style
Come cambia il modo di scrivere codice con i test


Scrivere PRIMA i test


Codice testabile


Rifattorizzazione


Scrivere codice testabile

- Spostare la maggior parte della logica nel model
- Eliminare le dipendenze tra i componenti
- Separare le responsabilità
- Evitare quando possibile metodi statici
- Limitare l’uso di oggetti singleton


Rifattorizzazione

- Più sicura
- Più facile
- Più frequente
- Migliora la qualità del codice


Spezzare il ciclo dello stress


Tipologia di test
- Unit
- Molti test molto veloci
- Testano singole funzionalità
- Indipendenti dal codice che NON stanno testando
- Functional
- Tipicamente più lenti
- Probabilmente più adatti per veriﬁcare regressioni che non per TDD

Strumenti
- Unit Test
- Lime (framework di test di symfony)
- PHPUnit + Stagehand_TestRunner
- Functional Test
- Framework di test di symfony
- Selenium
- Continuos Integration

Un Esempio
Uno tuffo dentro al TDD per lo sviluppo di componente reale


Requisiti
- Implementare un Web Service REST con firma delle chiamate
- Le chiamate devono essere firmate utilizzando il codice nonce e una chiave segreta
(condivisa da client e server)

- La firma viene generata utilizzando un codice NONCE
- Il codice nonce univoco, casuale e persistente tra creazione e utilizzo
- Il nonce deve essere eliminato dopo il suo utilizzo


Step 0
Deﬁnizione di una lista di test


TODO Test

- Il server genera un codice nonce di tipo stringa, univoco, di 32 caratteri
- La ﬁrma viene correttamente veriﬁcata
- Il codice nonce viene memorizzato quando viene richiesto/generato
- Il codice nonce viene eliminato quando viene utilizzato


Iterazione 1
Test:
Il server genera un codice nonce di tipo stringa, univoco, di 32 caratteri


Il Test
public function testGetNonce()
{
$server = new AuthServer();
$this->assertType('string', $server->getNonce());
$this->assertEquals(32, strlen($server->getNonce()));
$this->assertNotEquals($server->getNonce(), $server->getNonce());
}

Il Codice
class AuthServer
{
/**
* Genera un codice nonce univoco
*/
public function generateNonce()
{
return md5(uniqid(mt_rand(), true));
}
}


Iterazione 2
Test:
La ﬁrma viene correttamente veriﬁcata.


Il Test

/**
* Test metodo validateSignature()
*
* verifica tipo di dato restituito, test signature corretta e signature non corretta
*/
public function testValidateInvalidSignature()
{
$server = $this->createServer();

$secret = 'mySecret';
$nonce = 'nonce';
$signature = 'fakesignature';

$this->assertType('boolean', $server->validateSignature($signature, $secret, $nonce));
$this->assertFalse($server->validateSignature($signature, $secret, $nonce));

$signature = '6313fc22867e45185845408d9a4993f439440313';
$this->assertTrue($server->validateSignature($signature, $secret, $nonce));
}


Il Codice
/**
* Verifica la signature
*/
public function validateSignature($signature, $secret, $nonce)
{
$calculatedSignature = hash_hmac('sha1', $nonce, $secret);
return $calculatedSignature == $signature;
}


Iterazione 3
Test:
Il codice nonce viene memorizzato quando viene richiesto/generato


Il Test

/**
* Verifica che il codice none venga
* memorizzato una volta richiesto.
*
* Il test usa un oggetto mock per verificare che venga
* chiamato il metodo saveNonce($nonce) in AuthServer::generateNonce()
*
*/
public function testNoncePersistence()
{
$testNonceDataStore = $this->getMock('TestNonceDataStore');
$testNonceDataStore->expects($this->once())->method('saveNonce')->with($this->isType('string'));
$server = new AuthServer($testNonceDataStore);

$server->generateNonce();
}


Il Codice
class AuthServer /**
{ * Interfaccia per la persistenza del codice Nonce
/** * @author ftassi
* *
* @var NonceDataStore $dataStore
*/
*/
protected $dataStore; interface NonceDataStore
{
/** public function saveNonce($nonce);
* Costruttore }
*
* @param NonceDataStore $dataStore
*/
public function __construct(NonceDataStore $dataStore)
{
$this->dataStore = $dataStore;
}
/**
*/
{
return $calculatedSignature == $signature;
}
}


Iterazione 4
Test:
Il codice nonce viene eliminato quando viene utilizzato


Il Test

/**
* Verifica che il codice none venga
* memorizzato una volta richiesto.
*
* Il test usa un oggetto mock per verificare che venga
* chiamato il metodo saveNonce($nonce) in AuthServer::generateNonce()
*
*/
public function testNoncePersistence()
{
$testNonceDataStore = $this->getMock('TestNonceDataStore');
$testNonceDataStore->expects($this->once())->method('saveNonce')->with($this->isType('string'));
$dataStore->expects($this->never())->method('deleteNonce')->with($this->isType('string'));
$server = $this->createServer($testNonceDataStore);

$server->generateNonce();
}


Il Test

/**
* Verifica la rimozione del codice nonce
* in caso di richiesta valida
*/
public function testNonceRemovalForValidSignature()
{
$nonce = 'nonce';
$signature = '6313fc22867e45185845408d9a4993f439440313';

$dataStore = $this->getMock('TestNonceDataStore');
$dataStore->expects($this->once())->method('deleteNonce')->with($this->isType('string'));
$server = $this->createServer($dataStore);

$server->validateSignature($signature, $secret, $nonce);

}


Il Test

/**
* Verifica che il nonce non venga invalidato se la firma non Ã¨ valida
*/
public function testNonceRemovalForInvalidSignature()
{
$nonce = 'nonce';
$signature = 'fakesignature';

$dataStore = $this->getMock('TestNonceDataStore');
$dataStore->expects($this->never())->method('deleteNonce');
$server = $this->createServer($dataStore);

$server->validateSignature($signature, $secret, $nonce);

}


Il Codice

/**
*/
{
if($calculatedSignature == $signature)
{
$this->dataStore->deleteNonce($nonce);
return true;
}

return false;
}


THANK YOU
H-art
Via Sile, 41
31056 - Ca’ Tron (Treviso)

All rights reserved. This publication is protected by copyright.
No part of it may be reproduced, stored in a retrieval system,
or transmitted in any form, or by any means, electronic,
mechanical, photocopying or otherwise, without written
permission from the copyright owners.

Every effort has been made to ensure the accuracy of the
contents, but the publishers and copyright owners cannot
accept liability in respect of errors or omissions. Readers will
appreciate that the data are as up-to-date only to the extent
that their availability, compilation and printed schedules will
allow and are subject to change.

20100715 - TDD | Test Driven Development

TDD Test Driven Development

Recommended

Recommended

More Related Content

Similar to TDD Test Driven Development

Similar to TDD Test Driven Development (20)

TDD Test Driven Development

Editor's Notes