TDD für ein Gerät Communicator

Question

Ich habe über TDD gelesen, und würde es gerne für mein nächstes Projekt verwenden, aber ich bin nicht sicher, wie mit diesem neuen Paradigma meiner Klassen zu strukturieren. Die Sprache Ich mag würde verwenden, ist Java, obwohl das Problem nicht wirklich sprachspezifisch ist.

Das Projekt

Ich habe ein paar Stücke von Hardware, die mit einer ASCII-over-RS232-Schnittstelle kommen. Ich kann einfache Befehle ausgeben und einfache Antworten erhalten, und steuern, als ob von ihren Frontplatten. Jeder hat eine etwas andere Syntax und sehr unterschiedliche Sätze von Befehlen. Mein Ziel ist es, eine Abstraktion / Schnittstelle zu schaffen, damit ich sie alle durch einen GUI und / oder Remote Procedure Calls steuern kann.

Das Problem

Ich glaube, der erste Schritt eine abstrakte Klasse zu erstellen ist (ich bin schlecht Namen, wie etwa ‚Communicator‘?) Alle Sachen wie Serial I zu implementieren / O, und erstellen Sie eine Unterklasse für jedes Gerät. Ich bin sicher, es wird ein wenig komplizierter als das sein, aber das ist der Kern der Anwendung in meinem Kopf.

Nun, für Unit-Tests, ich glaube nicht, ich brauche die eigentliche Hardware oder eine serielle Verbindung wirklich. Was ich möchte, ist von Hand tun, um meine Kommunikatoren eines Inputstream und Outputstream (oder Reader und Writer), die von einer seriellen Schnittstelle sein könnte, eine Datei stdin / stdout, von einer Testfunktion geleitet, was auch immer. So würde ich nur die Communicator-Konstruktor diejenigen, die als Eingänge nehmen? Wenn ja, wäre es leicht, die Verantwortung stellen sie alle bis auf dem Test-Framework, aber für die reale Sache Einstellung, wer macht die eigentliche Verbindung? Ein separater Konstruktor? Die Funktion der Konstruktor ruft wieder? Eine separate Klasse, die Arbeit ist es zu ‚Verbinden‘ den Communicator auf die richtigen I / O-Streams?

Bearbeiten

Ich war über das Problem Abschnitt, um neu zu schreiben, Antworten auf die Frage zu erhalten, ich dachte, ich würde fragen, aber ich denke, ich es herausgefunden. Ich hatte (richtig?) Identifiziert zwei unterschiedliche Funktionsbereiche.

1) Der Umgang mit der seriellen Schnittstelle

2) Kommunikation mit dem Gerät (versteht seinen Ausgang & Erzeugen Befehle)

Vor ein paar Monaten hätte ich sie alle in einer Klasse zusammengefasst. Meine erste Idee in Richtung von dieser Loslösung war nur die IO-Streams an die Klasse übergibt, die das Gerät versteht, und ich kann nicht herausfinden, wer dann verantwortlich wäre, um die Ströme zu schaffen.

auf Umkehrung der Steuer mehr Forschung getan haben, ich glaube, ich habe eine Antwort. Verfügt über eine separate Schnittstelle und Klasse, das Problem # löst 1 und übergibt es an den Konstruktor der Klasse (n?), Das Problem # 2 lösen. Auf diese Weise ist es einfach, beide separat zu testen. # 1 von der eigentlichen Hardware-Anschluss und ermöglicht den Test Rahmen verschiedene Dinge zu tun. # 2 können, indem sie gegeben verspotteten # 1 getestet werden.

Klingt das vernünftig? Muss ich mehr Informationen teilen?

Answer 1

Mit TDD, sollten Sie lassen Sie Ihr Design entstehen , start small, mit kleinen Schritten und Ihre Klassen-Test durch Test, nach und nach wachsen.

GEKLäRT: Beginnen Sie mit einer konkreten Klasse, einen Befehl zu senden, Unit-Test mit einem Mock oder einem Stummel. Wenn es genug (vielleicht nicht mit allen Optionen) arbeitet, testen Sie es gegen Ihre reale Gerät, einmal, um Ihren Mock / Stub / Simulator zu validieren.

Wenn die Klasse für den ersten Befehl in Betrieb ist, startet einen zweiten Befehl Implementierung der gleiche Art und Weise: zuerst wieder Ihre Mock / Stub, dann einmal gegen das Gerät für die Validierung. Nun, wenn Sie Ähnlichkeiten zwischen den zwei Klassen zu sehen, können Sie Ihr abstrakte Klasse basiertes Design Refactoring - oder etwas anderes.

Answer 2

Es tut uns ist ein wenig Linux centric ..

Meine Lieblings-Weg-Gadgets zu simulieren, ist href="http://luv.asn.au/overheads/chrdev-talk.html" zum Zeichengerätetreiber schreiben dass simulieren ihr Verhalten. Dies gibt Ihnen auch Spaß Fähigkeiten, wie Bereitstellen einen ioctl () Schnittstelle, die das simulierte Gerät macht abnorm verhalten.

An diesem Punkt .. von Tests auf der realen Welt, ist es nur wichtig, die Gerät (e) Sie tatsächlich öffnen, lesen und schreiben.

Es sollte nicht zu schwer sein, das Verhalten Ihrer Geräte zu imitieren .. es klingt wie sie sehr grundlegende Hinweise nehmen und ganz einfache Antworten zurück. Wieder eine einfache ioctl () könnte das simulierte Gerät sagen, dass seine Zeit schlecht zu benehmen, so können Sie sicherstellen, dass Ihr Code angemessen solche Ereignisse verarbeitet. Zum Beispiel, nicht absichtlich auf jedem n-ten Befehl, wobei n zufällig auf den Aufruf von ioctl ausgewählt ist ().

Answer 3

Nachdem Sie die Änderungen sehen Ich glaube, Sie in genau die richtige Richtung. TDD neigt man zu einem Design von kleinen Klassen mit einer gut definierten Verantwortung zusammengesetzt zu fahren. Ich würde Echo auch tinkertim Rates - ein Gerätesimulator, die Sie steuern können, und „provozieren“ in auf unterschiedliche Weise zu verhalten für das Testen von unschätzbarem Wert ist

.