Refactoring WPF MVVM für erhöhte Testbarkeit

Question

Ich habe eine funktionale, aber chaotisch WPF MVVM-Anwendung geerbt. Zu meinem Ärger gab es praktisch keine Unit-Tests, die die Annahme MVVM etwas sinnlos machen. Also habe ich beschlossen, etwas hinzuzufügen.

Nachdem ich die tief hängenden Früchte ergriffen habe, fange ich an, in Schwierigkeiten zu geraten. Es gibt viel Code, der stark voneinander abhängig ist, insbesondere innerhalb der Eigenschaften und Methoden, die in den Ansichten verwendet werden. Es ist zum Beispiel üblich, dass ein Anruf eine Kette von "Eigenschaftsänderungs" -Ereignissen auslöst, die wiederum andere Anrufe auslösen und so weiter.

Dies macht es sehr schwierig zu testen, weil Sie enorme Mocks schreiben müssen und eine große Anzahl von Eigenschaften einrichten, um einzelne Funktionen zu testen. Natürlich müssen Sie es nur einmal pro Klasse tun und dann Ihren Mock und ViewModel bei jedem Test erneut verwenden. Aber es ist immer noch ein Schmerz, und es scheint mir, dass dies der falsche Weg ist. Es wäre sicherlich besser, zu versuchen, den Code zu brechen und ihn modularer zu machen.

Ich bin mir nicht sicher, wie realistisch das in MVVM ist. Und ich bin in einem Teufelskreis, denn ohne gute Tests mache ich mir Sorgen, den Build durch Refactoring zu brechen und gute Tests zu schreiben. Die Tatsache, dass es WPF MVVM ist, ist ein weiteres Problem, da nichts die Interdependenz zwischen View und ViewModel verfolgt - eine unvorsichtige Namensänderung könnte etwas komplett zerstören.

Ich arbeite in C# VS2013 und griff die Testversion von ReSharper, um zu sehen, ob es helfen würde. Es macht Spaß zu benutzen, aber es ist nicht so weit. Meine Erfahrung mit Komponententests ist nicht riesig.

Also - wie kann ich das vernünftig, methodisch und sicher angehen? Und wie kann ich meine vorhandenen Tools (und andere Tools) verwenden, um zu helfen?

Answer 1

1. beginnen im Herzen - Geschäftslogik

Ihre Anwendung löst einige Probleme der realen Welt und das ist, was Business-Logik darstellt. Ihre Ansichtsmodelle umschließen diese Geschäftslogikkomponenten, selbst wenn sie (Komponenten) noch nicht existieren (als separate Klassen).

Als Ergebnis sollten Sie diese Ansicht Modell ist leichte, Datenaufbereitung/Umlagerung Objekt übernehmen. All das schwere Heben sollte innerhalb von Geschäftslogikobjekten erfolgen. View-Modell sollte mit Rohdaten bedient werden, Anzeige bereit.

2. modularisieren

diese wichtige Voraussetzung im Auge zu haben (VM = keine BL) bewegen Business-Logik-Komponenten zu trennen, möglicherweise modulare Projekte.Organisation von BL in modularer Weise führt oft in Projekten Struktur ähnlich:

• Company.Project.Feature.Contract - Schnittstellen, Organisationen, DTOs in Zusammenhang mit Merkmale
• Company.Project.Feature - Umsetzung Vertrag
• Company.Project.Feature.Tests - Tests für Funktion Implementierung

Ihr Ziel mit # 1 und # 2 sollen einen Zustand erreichen, in dem das Verlassen von WPF und Ersetzen durch die Konsolenschnittstelle nur das Schreiben der Konsolenschnittstelle und das Verdrahten derselben mit der BL-Schicht erfordern sollte. Alles, was mit WPF zusammenhängt (Views, ViewModels), kann Shift-gelöscht werden und eine solche Aktion sollte nichts ändern.

3. IoC für Testbarkeit

Setzen Sie sich mit Dependency Injection vertraut und abstrakt, wo nötig. Einführung eines IoC-Containers. Machen Sie Ihren Code nicht auf Implementierung angewiesen, verlassen Sie sich auf Vertrag. Wenn das Ansichtsmodell eine Abhängigkeit von der BL-Implementierung annimmt, tauschen Sie es gegen die BL-Abstraktion aus. Dies ist einer der notwendigen Schritte, um View-Modelle testbar zu machen.

So würde ich anfangen. Auf keinen Fall ist dies eine erschöpfende Liste, und ich bin überzeugt, dass Sie in Situationen geraten werden, in denen das Festhalten nicht ausreicht. Aber das ist, was es ist - working with legacy code is not an easy task.