Nel mio precedente post ho rivolto la domanda su come testare la classe Alarm senza modificarla. Matteo Baglini ha provato a rispondere alle domande esprimendo qualche perplessità proprio sull'ultima. In effetti rispondere è meno banale di quello che sembra.
Riporto nuovamente la classe Alarm originale:
public class Alarm
{
private const double LowPressureTreshold = 17;
private const double HighPressureTreshold = 21;
Sensor _sensor = new Sensor();
bool _alarmOn = false;
private long _alarmCount = 0;
public void Check()
{
double psiPressureValue = _sensor.PopNextPressurePsiValue();
if (psiPressureValue < LowPressureTreshold || HighPressureTreshold < psiPressureValue)
{
_alarmOn = true;
_alarmCount += 1;
}
}
public bool AlarmOn
{
get { return _alarmOn; }
}
}
Qual è il problema di testare questa classe senza modificarla?
La dipendenza dalla classe Sensor. In quanto viene fatta la new su cui non ho il controllo.
La soluzione che propongo è liberamente ispirata dal libro Working Effectively with Legacy Code di Michael Feathers che consiglio vivamente se avete a che fare con codice legacy.
Creo un nuovo progetto a cui aggiungo il file sorgente che devo testare, in questo caso il file Alarm.cs. La solution avrà una struttura tipo questa:
Occhio che affincè il barbatrucco funzioni il progetto di test deve stare in una cartella di livello superiore al progetto testato. Infatti vedete che dal progetto Alarm.Tests vedo la cartella AlarmApplication. In questo modo il file Alarm.cs appartiene contemporaneamente ai due progetti non è una copia.
Ora otterrò un errore di compilazione perchè in questo progetto la classe Sensor non esiste.
Aggiungo quindi una nuova classe Sensor nel progetto di test la cui implementazione è completamente sotto il mio controllo:
class Sensor
{
public static double NextValue { get; set;}
public double PopNextPressurePsiValue()
{
return NextValue;
}
}
Scrivere il test della classe Alarm ora è banale:
[Test]
public void ShouldSetAlarmOn()
{
Sensor.NextValue = 18;
var alarm = new Alarm();
alarm.Check();
Assert.That(alarm.AlarmOn, Is.True);
}
}
Questa è una tecnica molto utile, da usare con cautela nel caso in cui si debba fare un refactoring a codice legacy non testato e ci si voglia assicurare di non creare regressioni al comportamento attuale.