Mehrsprachiges Testframework

Es gibt einige andere Optionen für Sprachen, die sowohl auf der CLR als auch auf der JVM ausgeführt werden. Einige davon haben bereits eigene Unit-Test-Frameworks.

Zum Beispiel kommt Ruby mit Test Unit und existiert in Source-kompatiblen Versionen für beide Laufzeiten ( JRuby und Iron Ruby - beide sind Ruby 1.8 Version kompatibel.

Wäre eine gute Entschuldigung, Ruby zu lernen, wenn du es nicht schon weißt ...

Interessante Frage ..

Ich denke, dass Sie xUnit-Implementierungen für Java (am wahrscheinlichsten JUnit) und .NET verwenden können. Aber dein Testcode muss es in einer dritten Sprache geschrieben haben, wahrscheinlich einfaches DSL zum Testen, das du selbst gestalten kannst. Diese Sprache soll in Java- und C # -Quelldateien übersetzt werden.

Andere Möglichkeit besteht nicht darin, sich mit der eigenen Sprache herumzuärgern und eine existierende Sprache zu übernehmen. Z.B. Python hat Implementierungen für beide Plattformen: Jython (Java) und IronPython (.NET). So können Sie Tests in dieser Sprache schreiben. Python hat seine eigene gebündelte xUnit-Implementierung: unittest Paket.

Ich sehe zwei Strategien:

• Fügen Sie den Code zum Testen auf einer Art von Server ein, damit Sie die Methoden zum Remote-Testen aufrufen können. Dies würde Ihnen erlauben, jede Testsuite zu verwenden.

• Schreiben Sie die Tests in etwas wie J # oder einer anderen Sprache, die Sie problemlos auf .NET und Java abbilden können. Dies bedeutet, dass Sie die Tests einmal schreiben und dann den Testcode in etwas übersetzen, was zwei verschiedene Test-Frameworks verstehen können.

Ich schlage vor, den zweiten Ansatz zuerst zu versuchen. Es wird Tests zu einem viel komplexeren Testaufbau viel schneller machen. Der erste Ansatz ist wahrscheinlich einfacher einzurichten, aber die Tests werden langsamer und Sie müssen den Server irgendwo in den Tests starten und abbauen.

Gurke ist ein großartiger Rahmen für das Schreiben von Spezifikationen. Die Spezifikationen werden durch Schrittdefinitionen unterstützt, die geschrieben werden können, um sowohl die .net- als auch die Java-Implementierung zu steuern.

Was ich interessant finde, ist, dass Sie nicht versuchen, den Aufwand von Komponententests zu duplizieren, aber nicht für die Anwendung selbst. Warum schreiben Sie nicht die Anwendung core & amp; Unit-Tests in Java und dann ikvm und nur die UI-Ebenen in C # und Java mit separaten Komponententests basierend auf der jeweiligen Technologie . (Oder Grasshopper wenn Sie ein .NET-Shop sind)?

Ich empfehle, die Granularität Ihrer Frage noch einmal zu überprüfen. Es impliziert Unit-Testing, aber warum nicht auf Funktions- / Systemebene testen. In diesem Zusammenhang wird FIT zu einer Wahl.

Als Beispiel haben wir eine Client-Server-App in Java. Wir verwenden FIT als alternativen Client: Wir können Html-Eingabedateien angeben und mit etwas Kleber (auch Fixtures genannt) können wir den Server treffen.

Die gute Nachricht ist, dass dies nichts mit der Sprache auf dem Server zu tun hat, und die Html-Dateien können als Akzeptanztests verwendet werden.

Die schlechte Nachricht ist, dass FIT nur ein Rahmenwerk ist: Es kann viel Klebstoff brauchen. Außerdem muss man erkennen, dass dies keine Unit-Tests sind. Nicht nur die Granularität ist unterschiedlich, sondern auch die Geschwindigkeit ist unterschiedlich. h. eine große Anzahl von Tests kann aus der Sicht eines Komponententests nicht in "normaler" Zeit ablaufen. (Wir laufen unsere nachts und nur eine kleine Teilmenge während CI-Build.)

Ich bin Autor von jni4net , Open-Source-Intra-Prozess-Brücke zwischen JVM und CLR. Es ist auf JNI und PInvoke aufgebaut. Kein C / C ++ Code benötigt. Ich hoffe, es wird dir helfen.