UnitTests: Tests direkt in zu testende Klasse integrieren

Hallo allerseits,

bei den in VS integrierten Tests stört mich, daß immer ein eigenes TestProjekt erzeugt wird. Außer in der Solution besteht keinerlei Zusammenhang zwischen der Test-Klasse und der zu testenden Klasse. Gibt es nicht vielleicht eine Möglichkeit, die Test-Methoden direkt in die entsprechende Klasse zu schreiben, damit man immer alles beisammen hat? Also z.B. so:

class ClassToTest
{
  public object DoSomething(object someValue)
  {
     // ...
  }

  #region Tests

  [TestFixure]
  public void TestDoSomething()
  {
    // ...
  }

  #endregion
}

Schöne Grüße,
Christian

Hallo MrSparkle

An deinem Ansatz stört mich (viel mehr), dass ich damit gezwungen wäre alle benötigten DLLs des Unit-Test Frameworks (hier die Visual Studio eigenen DLLs) mit auszuliefern. Ich bin mir nicht mal sicher ob das lizenztechnisch erlaubt ist.

Was stört dich an dem zusätzlichen Projekt denn? Ich habe in meinen Test-Projekten Mock-Objekte, Helper-Klassen und ggf. Test-Files. Würdest du die dann alle mit in dein eigentliches Projekt aufnehmen wollen? Ist das dann sauber 😉 ?

Ich finde die Lösung über die separaten Test-Projekte sehr schön und die Solution hält alles zusammen. Außerdem helfe ich mir noch mit dem Namen der Testprojekte.

Wenn ich eine Library "Acme.MyLib" und eine Library "Acme.OtherLib" habe (nein, ich verwende kein "Lib" als Suffix), dann habe ich ein Testprojekt "Acme.MyLib.Tests" und ein Testprojekt "Acme.OtherLib.Tests". So ist alles zusammen und ich glücklich 😮)

Grüße
Flo

Was stört dich an dem zusätzlichen Projekt denn?

Wenn ich bleistiftsweise mein Projekt an einen anderen Entwickler weitergebe, um sie vervollständigen zu lassen, dann braucht er auch das TestProjekt dafür. Er hat aber seine eigene Solution, die er zum Entwickeln braucht und muß das TestProjekt dort erst integrieren, die Verweise wieder hinzufügen usw.
Wäre alles in einem Projekt, könnte er damit machen was er wollte, und die Tests trotzdem jederzeit ausführen.

Genau das gleiche bei mir lokal: Ich verwende eine Library in mehreren Solutions und müßte dann jedesmal das TestProjekt in die Solution hinzufügen, Verweise setzen usw.

Das alles mit vielen unterschiedlichen Libs, mehreren Solutions usw.

Am besten wäre es echt, wenn man alles beisammen hätte. Aber so wie's klingt, gibs die Möglichkeit wohl gar nicht...?

Klar kannst Du das so machen, dann lieferst Du eben an Deine Kunden den ganzen Quatsch mit aus. Kannst die Lizensierungsprobleme ja dadurch umgehen indem Du NUnit verwendest.

Deine Argumentation ist nicht nachvollziehbar. Wer um Himmels willen hat solch aufwendige Prozesse? Da stellt man sich ein Versionskontrollsystem hin auf das jeder Zugriff hat und so hat jeder genau die Solution welche der andere auch hat. Und die Tests werden von einem BuildServer nach dem Einchecken (oder währenddessen, je nach System) durchlaufen. Lokal führt man Tests nur während der Entwicklung der Tests und zu Kontrollzwecken aus, aber nicht zur Validierung des gesamten Entwicklungsprozesses.

Hallo Florian Reischl,

An deinem Ansatz stört mich (viel mehr), dass ich damit gezwungen wäre alle benötigten DLLs des Unit-Test Frameworks (hier die Visual Studio eigenen DLLs) mit auszuliefern.

wozu gibt es [Conditional ("DEBUG")] oder [Conditional ("TEST")]? Es geht ja nicht nur um die DLLs, es wäre ja schon unsinnig, den Testcode in der fertigen Anwendung zu haben, aber mit Conditional hat man ja weder das eine noch das andere Problem.

herbivore

Hat denn noch niemand die gleichen Probleme wie ich gehabt? Gibt es dafür wirklich keine Lösung? Vielleicht mit NUnit o.ä.?

Nein, weil diejenigen die Unittests benutzen nicht so eine Projektierung machen.

Evtl hast Du/Ihr da auch einfach nur das ganze falsch verstanden und/oder habt einfach das/die Projekte komplett falsch aufgebaut.

Entweder das gesamte Projekt ist in einer Solution, oder aufgeteilt.
Ist es aufgeteilt, greifen andere Solutions nur auf die erzeugten Binaries zu.
Macht man soetwas müssen auch die Binaries mit ins SCM.

Dadurch kann jede Seperation getrennt entwickelt werden und der Aufwand den Du beschreibst ist vollkommen unnötig.

Muss einer eine Lib entwickeln wird dieses LibProjekt getrennt aus dem SCM gezogen, entwickelt getestet und eingecheckt.

FZelle: Full Ack.

Ok, vielen Dank für die Aufklärung! Ich hab da offensichtlich wirklich was falsch verstanden, obwohl ich hätte schwören können, soetwas mal in einem Microsoft-Tutorial gesehen zu haben (ich glaube es waren die legendäre RocketCommander Video-Tutorials).

Aber eine Frage hätte ich dazu noch: Was, wenn man eine Klasse einer Library testen möchte, die nicht veröffentlich wurde, und nur intern genutzt wird? Nehmen wir mal an, daß viele andere Klassen in der Library diese interne Klasse nutzen, und ich deshalb erstmal diese Klasse zuerst testen möchte. Aus einem anderen Projekt kann ich ja nicht darauf zugreifen. Wie geht man dabei vor?

Hallo MrSparkle,

wenn das Projekt auch "dir" gehört kannst du folgendes verwenden: InternalsVisibleTo

Also wenn ich die ganze Unittesterei richtig verstanden habe ist das eher eine Blackbox Geschichte
D.h. man testet nicht einzelne interne Klassen, sondern nur die öffentlichen Schnittstellen die auch dem User (Programmierer) zur Verfügung stehen auf die Richtige funktionalität.

Das wäre dann kein Unit Test sondern ein Integrationstest auf der entsprechenden Ebene.

Wie Du testest kommt ganz auf Deine Teststrategie an.