Wie startet man alten und neuen Code im Unit-Test?

Question

Ich gebe zu, dass ich fast keine Erfahrung der Unittests habe. Ich habe es vor einiger Zeit mit DUnit versucht, aber aufgegeben, weil es so viele Abhängigkeiten zwischen Klassen in meiner Anwendung gab. Es ist eine ziemlich große (etwa 1,5 Millionen Quellzeilen) Delphi-Anwendung und wir sind ein Team, das es aufrechterhält.

Das Testen für jetzt wird von einer Person durchgeführt, die es vor der Veröffentlichung verwendet und Fehler meldet. Ich habe auch einige GUI-Tests in TestComplete 6 eingerichtet, aber es scheitert oft an Änderungen in der Anwendung.

Fett für Delphi wird als persistance Framework gegen die Datenbank verwendet. Wir sind uns alle einig, dass Unittesting der richtige Weg ist und wir planen, eine neue Anwendung in DotNet mit ECO als Persistenz-Framework zu schreiben.

Ich weiß einfach nicht, wo ich anfangen soll mit Untistesting ... Irgendwelche guten Bücher, URL, Best Practice etc?

Answer 1

Nun, die Herausforderung in Unit-Tests ist nicht das Testen selbst, aber in schreiben testbaren Code. Wenn der Code geschrieben wurde nicht über das Testen denken, dann werden Sie wahrscheinlich eine wirklich harte Zeit haben.

Wie auch immer, wenn Sie refactor können, Refaktor, um es testbar zu machen. Mischen Sie die Objekterstellung nicht mit der Logik, wann immer dies möglich ist (ich kenne Delphi nicht, aber es könnte ein Framework für die Abhängigkeitsinjektion geben, das dabei hilft).

This blog hat viele gute Einblicke zum Testen.Überprüfen Sie zum Beispiel this article (mein erster Vorschlag basierte darauf).

Versuchen Sie zunächst, die Blattknoten Ihres Codes zu testen, also die Klassen, die nicht von anderen abhängig sind. Sie sollten einfacher zu testen sein, da sie keine Mocks erfordern.

Answer 2

Einer der beliebtesten Ansätze besteht darin, die Komponententests zu schreiben, während Sie den Code ändern. Alle neuen Codes erhalten Komponententests, und für jeden Code, den Sie ändern, schreiben Sie zuerst den Test, verifizieren ihn, ändern ihn, verifizieren ihn erneut und schreiben/reparieren dann alle Tests, die Sie aufgrund Ihrer Änderungen benötigen.

Einer der großen Vorteile einer guten Komponententestabdeckung besteht darin, dass Sie überprüfen können, ob die von Ihnen vorgenommenen Änderungen nicht versehentlich etwas anderes kaputt machen. Mit diesem Ansatz können Sie dies tun, während Sie sich auf Ihre unmittelbaren Bedürfnisse konzentrieren.

Der alternative Ansatz, den ich verwendet habe, ist meine Unit-Tests via Co-Ops :)

Tests

Answer 3

Schreibeinheit für Legacy-Code zu entwickeln, in der Regel eine Menge Refactoring erfordert. Excellent Buch, das dies ist Michael Feathers „Effektives Arbeiten mit Legacy Code“

Ein weiterer Vorschlag umfasst: eine Einheit Testabdeckung Werkzeug benutzen, um Ihre Fortschritte bei dieser Arbeit anzuzeigen. Ich bin mir nicht sicher, was die guten Coverage-Tools für Delphi-Code sind. Ich denke, das wäre eine andere Frage/Thema.

Working Effectively with Legacy Code

Answer 4

für.NET diese Unittesting zu lesen: "The Art of Unit Testing: mit den Beispielen in .NET"

Über besten pratices:
Was sagten Sie, ist richtig: Manchmal ist es schwierig zu schreiben Unit-Tests wegen der Abhängigkeit zwischen Klassen ... Also schreiben Unit-Tests kurz nach oder kurz vor ;-) die Umsetzung der Klassen. Wenn Sie Schwierigkeiten haben, die Tests zu schreiben, bedeutet das vielleicht, dass Sie ein Designproblem haben!

Answer 5

Wenn Sie mit Legacy-Code arbeiten, sind Pseudo-Objekte sehr nützlich, um Komponententests zu erstellen.

Werfen Sie einen Blick auf diese Frage zu Delphi und spottet: What is your favorite Delphi mocking library?