Jump to content
Unity Insider Forum

Unit Test missing reference


chrische5

Recommended Posts

Hallo

 

Ich wollte mich gestern mal mit dem Thema Unit-Tests bei Unity etwas vertraut machen und habe mir dazu folgendes angeschaut:

https://www.raywenderlich.com/9454-introduction-to-unity-unit-testing

Das habe ich gemacht und soweit auch verstanden. Nun wollte ich das ganze in meinem aktuellen Projekt probieren und bin die Schritte durchgegangen. Aber ohne überhaupt ein Test geschrieben zu haben, kann ich das Projekt nun nicht mehr kompilieren und bekommen viele, viele missing reference fehlermeldungen. Dabei handelt es sich ausschließlich um um fremde assests, die ich ins Projekt importiert habe. 

Ich kann nur wild spekulieren, was da genau passiert, aber ich vermute, dass ich deren Assemblies irgendwo eintragen muss.

Kann mir da jemand mit mehr Ahnung helfen? 

Danke

Christoph

Link zu diesem Kommentar
Auf anderen Seiten teilen

Ohne jetzt genau zu wissen, wo es kracht: Alle Tests müssen in einer Assembly sein, die NUnit und Unitys Testkram referenziert.

Hier steht ein bisschen was. Theoretisch kann man auch den Test Runner öffnen und den als Wizard benutzen, um einen Order mit Test-Assembly zu erstellen - da habe ich aber in Unity 2018 und 2019 schlechte Erfahrungen mit gemacht, hat mir die Project View zerschossen. Ich sehe gerade: Das ist scheinbar das, was in deinem Artikel da gemacht wird.

Du kannst dir auch einmalig so eine Asmdef zusammenbauen und die dann immer kopieren, so mache ich das :P

Aussehen muss die so:

grafik.png

Nur im Editor, nunit, die beiden Unity-Test-Assemblys und der Constraint war auch ganz gut :)

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 2 Stunden schrieb chrische5:

Kann es sein, dass viele Assets aus dem store keine Assemblies mitbringen?

Ja, der Asset Store ist da sehr unaufgeräumt. Den gibt's halt auch schon länger als asmdefs oder den Package Manager. Man ist da nicht schlecht beraten, wenn man die... "fahrlässigeren" Pakete nimmt, selber in ein lokales Repo schmeißt und dann da seine Änderungen maintained. Gilt auch für Art Assets. Man muss ja quasi bei jedem Paket die Größen oder irgendetwas anderes fixen.

Ist aber auch kein ganz einseitiges Thema. Jede Assembly wird von Unity bei einem Desktop Standalone Build konsequent in jeweils eine DLL kompiliert, die dem Build beigelgt wird. Wenn du also ein Spiel mit Soda machst, kann jemand das installieren und Soda als DLL da rausziehen. Hab nach wie vor keinen Plan, was man dagegen tun könnte. Würde ich aber lustig finden, irgendwann mal über eine Soda-DLL in einem Steam-Release zu finden :P

Link zu diesem Kommentar
Auf anderen Seiten teilen

Hallo 

 

okay, dann war ich ja gar nicht Donau dem Holzweg. Nun habe ich zumindest theoretische die Möglichkeit, Tests zu schreiben. Das scheint mir aber auch nicht ganz so einfach zu sein. Ich sehe gerade wenig Möglichkeiten, auf meinen GameObjects zuzugreifen. Habe ich da einen Denkfehler? Wie komme ich an Objekte aus der Hierarchie? Muss ich die alle zu Prefabs machen?

 

christoph

Link zu diesem Kommentar
Auf anderen Seiten teilen

Unity hat da verschiedene Ansatzpunkte. Erstmal hast du Edit Mode Tests und Play Mode Tests. Im Edit Mode Test kannst du alles mögliche testen, aber wenn du eine komplette Szene haben willst in der Dinge passieren, kannst du dafür einen Play Mode Test machen und die Szene laufen lassen.

Auch in einem Edit Mode Test kannst du aber Objekte erstellen und Dinge mit ihnen tun. Dafür hast du [SetUp] und [TearDown], auch wenn du nicht daran gebunden bist.

private GameObject thing;
private SomeComponent someComponent;

[SetUp]
public void SetUp()
{
  thing = new GameObject("Thing");
  someComponent = thing.AddComponent<SomeComponent>();
}

[TearDown]
public void TearDown()
{
  Object.DestroyImmediate(thing);
}

[Test]
public void DestroyComponentIsNotImmediate()
{
  Assert.IsNotNull(someComponent);
  Destroy(someComponent);
  Assert.IsNotNull(someComponent);
}

Wenn du jetzt eine vorhandene Struktur, wie z.B. eine existierende Szene testen willst, dann sind das keine Unit Tests mehr und es wird etwas schwieriger. Da musst du meines Wissens nach selber Datenstrukturen bauen oder nutzen. GameObject.Find ist natürlich uncool, kann aber einfacher sein als für Test Cases irgendwelche Daten in die Szene zu knallen. Mit dem EditorOnly-Tag kannst du zwar dafür sorgen, dass zusätzliche Strukturen für Tests nicht als Müll im Build langen, aber anlegen und pflegen muss man's trotzdem. Naja, dasselbe gilt für GameObject-Namen.

Du musst dir halt immer bewusst machen, was du testen willst. Wenn du eine Klasse testen willst, dann machst du nen Unit Test. Und das machst du, indem du für den Test eine kleine Umgebung aufbaust (siehe Code) und da drin rumstocherst. Wenn du also die Bewegung des Spielers automatisiert testen willst, machst du das eher nicht in einer vorgebauten Szene. Wenn du aber z.B. eine Szene testen willst, dann musst du schauen, wie du deinen Tests beibringst, die Szene zu verstehen und nutzen zu können.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Archiviert

Dieses Thema ist jetzt archiviert und für weitere Antworten gesperrt.

×
×
  • Neu erstellen...