Ich habe versucht, mein Team zu motivieren, unsere Entwicklungsfähigkeiten zu verbessern, indem Sie TDD folgen. Es ist eine großartige Erfahrung, aber an einigen Punkten habe ich gemerkt, dass die meisten von ihnen aufgrund der folgenden Probleme aufgehört haben zu tun:Wie folgt TDD Prinzipien mit Klasse mit Fabriken
1/Wir entwickeln "Broker" ausgelöst, wenn etwas passiert und entwickelt, um eine Reihe von Aktionen (E-Mails senden, verarbeite die Daten, konvertiere Dateien ...).
2/Alle Broker werden geladen, wenn die Anwendung startet, dank einer einfachen Activator.CreateInstance(brokerType)
.
3/Einer unserer Broker soll Datensätze aus einer Excel-Datei extrahieren und versuchen, zugehörige Datensätze in einer Datenbank zu finden. Um dies zu tun verwenden wir nur den Code unten:
public void Process(string file)
{
using (var sun = new SunSystemExcelDataSource(ExcelDatasourceFactory.Create(file)))
{//...}
}
Dieser Code ruft eine Fabrik, eine Klasse zurückkehrt (abgeleitet von IExcelSource
) in der Lage zu analysieren, um die angegebenen Excel-Datei (XLS vs XLSX) und dann wird es als Parameter übergeben zum SunSystemExcelDataSource
Konstruktor.
Frage: Diese Methode wird kaum testbar. Ich habe mich gefragt, ob Sie uns ein paar Tipps geben könnten, um die Testfähigkeit zu verbessern.
Wie können Testklassen, die sich auf Fabriken stützen, im Allgemeinen gebaut werden?
Code:
public void Initialize(ILog log, AppSettings settings)
{
_log = log;
_hrdb = DbDatasourceFactory.CreateHrdbDatasource(settings.HrdbConnectionString);
_processor = new K2Processor(settings.SettlePaymentWorkflow);
_sunFolderPath = settings.SunSystemExcelFolderPath;
}
Die Fabrik sollte kein statischer Typ sein, aber die Abhängigkeit als auch injiziert bekommen . Auf diese Weise verspottet man auch die Factory, die dann das testbare Objekt zurückgibt. –
Microsoft Shims und Fälschungen können statische Methoden vortäuschen. Wir können das benutzen, –