Ich versuche, Test Driven Development als Einzelentwickler zu machen (möglicherweise wird das Team auf vier erhöht). Ich habe Erfahrung mit NUnit in begrenztem Umfang für Unit-Tests.
Ich entwickle dieses System seit einigen Jahren (VB.NET). Der Entwickler vor mir arbeitete drei Jahre an dem System und er bevorzugte den Ansatz von Martin Fowlers Transaction Script, was bedeutet, dass es große Klassen mit großen monolithischen Funktionen gibt, die Design und Wiederverwendbarkeit so gut wie gar nicht berücksichtigen.
Ich habe mir einige der Mocking-Frameworks angesehen, die für Nunit verfügbar sind, und ich glaube, die einzige Option, die ich habe, ist das kommerzielle Produkt TypeMock ( RhinoMock vs. TypeMock vs. NUnit's Mocking? ), da es Ihnen ermöglicht, Klassen nachzuahmen, die keine abstrakten und ohne Schnittstellen sind. Ist das korrekt?
Ich habe einige Posts gelesen, die darauf hindeuten, dass dies nicht der Fall ist. Daher der Grund für diese Frage. Kann ich freie Transformer-Frameworks für Transaktionsskript / monolithische Systeme verwenden?
Wenn Sie keine abstrakte Klasse oder Schnittstelle haben, müssen Sie Produkte wie TypeMock oder Microsofts Fakes .
Gehen Sie nicht diesen Weg hinunter. Der Hauptvorteil von TDD besteht darin, dass Sie dazu gezwungen werden, Code lose zu koppeln und Abstraktionen zu löschen. Ohne dies werden Ihre Tests lächerlich schwer einzurichten und zu warten.
Was Sie wirklich tun müssen, ist das Refactoring. Langsam. Hier ist meine Empfehlung.
Spottungsklassen ohne Schnittstellen können für Code nützlich sein, den Sie nicht kontrollieren. Aber es ist immer noch schwer und wird mit der Zeit unhandlich und kompliziert.
Lassen Sie Ihre Tests mit Ihnen sprechen. Wenn Ihre Tests schwer zu handhaben oder zu kompliziert zu installieren sind, bedeutet dies, dass Ihr Code refaktoriert werden muss. Ignorieren Sie dieses Feedback nicht.
Tags und Links .net unit-testing nunit mocking