Ecco le varie soluzioni postate per il micro-esercizio di TDD:
- http://pastie.org/994235 - C#, TDD con mock objects
- http://pastie.org/994831 - C#, TDD con mock objects
- http://pastie.org/994969 - C#, TDD con mock objects
- http://pastie.org/997427 - Python, TDD
- test du accettazione: http://pastie.org/1001378
unit test e codice risultante: http://pastie.org/1001380 - Python, TDD con mock objects
- http://pastie.org/1003595 - Java, TDD, descrizione
La scrittura dei test ha fatto si che Alarm in tutte le soluzioni rispetta piú di prima il OCP. Cioé la dipendenza Sensor viene passata (nel costruttore o nel metodo). E questo come sola conseguenza della scrittura dei test.
Le soluzioni con TDD con mock objects in C# dopo la scrittura dei test rispettano il DIP. Cioé sia Alarm che Sensor ora dipendono dal tipo astratto ISensor. Mentre la soluzione Java in TDD non rispetta il DIP.
Delle soluzioni in Python non si puo dire se rispettano il DIP, perché in Python non é possibile definire interfaccie. Se l'autore ha applicato in modo consistente il concetto di protocollo (che sostituisce le interfaccie nei linguaggi non tipizzati cosi come nei Template del C++) non si puo dire con cosi poco codice.
Invece solo alcune soluzioni sostituiscono il getter con codice piú OO, quindi deduco che non é una conseguenza diretta del testare Alarm ma una scelta intenzionale.
Tutte le soluzioni sono sufficientemente buone. Chi lo desidera é incoraggiato a commentare similitudini e differenze tra le varie soluzioni e a postare le sue considerazioni.
Un modo pratico per confrontare le soluzioni, é chiedersi come il codice di Alarm si presta a essere facilmente modificato/evoluto, ad esempio a seguito di queste 2 nuove richieste:
- Il sensore attuale misura psi, aggiungere il supporto a un sensore che misura in bar (e quindi anche i threashold sono in bar)
- invece di notificare solo se l'allarme é on (OnAlarm booleano), notificare di quanto la misurazione del sensore ha sforato (e.g. OnAlarm double).