Unit Testing eines C # / XNA-Spielprojekts

Ich habe in der Spieleentwicklung gearbeitet, seit ich mit dem Programmieren angefangen habe, aber nie sehr ernst. Ich arbeite als Entwickler von Geschäftsanwendungen, arbeite aber in meiner Freizeit an einigen Spielen.

In der Geschäftswelt (auf dem Web-Dev-Stack von Microsft) wird ASP.NET MVC immer beliebter, da die Funktionsweise der Benutzeroberfläche auf einfache Weise getestet werden kann.

Ich frage mich, mit welchen Entwurfsmustern (MVC, MVP, MVVM usw.) man ein Spiel schreiben könnte, in dem die gesamte Spiellogik leicht auf Einheiten getestet werden kann. Ist das möglich oder machbar? Verschwende ich meine Zeit, ist es besser, vollständige Builds durchzuführen und dann "Integrationstests" anstelle von Komponententests durchzuführen?

Beispielcode wäre toll, aber eine Beschreibung ist auch nützlich.

(Ich habe versucht, ein Unit-Testing-Tag hinzuzufügen, habe aber nicht den erforderlichen Repräsentanten ...)

— Nate
quelle

Hier ist ein guter Artikel, den ich gefunden habe und der eine Architektur für die Aufteilung von Funktionen beschreibt, damit diese nicht nur leicht wiederverwendbar, sondern möglicherweise auch einfacher zu testen sind:

http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/

Einige Spiele werden von einem MVC-ähnlichen Muster profitieren. Brettspiele wie Schach und Kartenspiele kommen in den Sinn. In den meisten Fällen ist dies jedoch ein massiver Overkill.

Ich persönlich halte es für ausreichend, nur algorithmische Einheiten zu testen. Dinge, auf die Sie angewiesen sind, um beim Schreiben von Gameplay-Code "nur zu funktionieren", und bei denen es schwierig sein kann, Probleme aufzuspüren, wenn dies nicht der Fall ist. Dinge wie Kreuzungstests oder Netzwerkcode.

(Dinge, die idealerweise in ein Framework von Drittanbietern eingebaut werden, damit Sie sie nicht schreiben oder testen müssen!)

Eine Technik, die ich gerne zum Testen von Einheiten im Zusammenhang mit Spielen verwende, ist der so genannte "visuelle Einheitentest". Das Grundkonzept besteht aus einer einfachen Zeilenwiedergabe des fraglichen Codebits (z. B. einer Schnittfunktion) und einigen grundlegenden Tasten- oder Mauszuweisungen zur Manipulation der Eingaben. Niemand sagte, Unit-Tests müssten automatisiert werden - sie müssten lediglich die Dinge in einzelne Units aufteilen und sie testen.

— Andrew Russell
quelle

Gute Antwort. Ich wollte auch genau diesen Artikel posten. Game Object-Komponentensysteme sind eine großartige Möglichkeit, Logik zu trennen und diese einzeln zu testen. Was jedoch kein Komponententest kann, sind die komplexen Wechselwirkungen mehrerer Pfade der Spiellogik, die in zufälliger Reihenfolge in Echtzeit interagieren. Das wäre wie der Versuch, die Wettervorhersage zu testen. :)

— LearnCocos2D

Ja, ich mache auch kleine Tester, die bestimmte Teile der Funktionalität isolieren. Ich stelle sicher, dass alle Änderungen, die ich an APIs usw. vornehme, immer noch funktionieren. Viel einfacher, die Funktionalität in Ihrem nächsten Projekt wiederzuverwenden.

— Iain

Ja, gute Antwort, und ich mag den Link. Und ich stimmte bis zur letzten Zeile mit allem überein: "Niemand sagte, Unit-Tests müssten automatisiert werden." :) Müssen , vielleicht auch nicht - aber alles, was ich gelesen habe, impliziert (oder sagt direkt), dass Komponententests automatisiert werden sollten , bis zu dem Punkt, an dem Sie nur einen einzigen Knopf drücken, um alle Ihre Tests auszuführen. Andernfalls ist es weniger wahrscheinlich, dass Sie die Tests oft genug ausführen, je mehr Arbeit für die Ausführung erforderlich ist. Zugegeben, wenn es sich um Anzeigecode handelt , kann es sehr viel schwieriger sein, Einheiten zu testen, wenn überhaupt möglich.

— Cyclops

Fast vier Jahre später habe ich ein besseres Verständnis dafür entwickelt, warum der "visuelle Komponententest" so gut funktioniert: Komponententests sind ein Entwicklungswerkzeug. Ein typischer automatisierter Unit - Test kann Ihnen sagen , dass etwas ist gebrochen. Mit einem visuellen Einheitentest können Sie jedoch sehr komplizierte Algorithmen untersuchen und schnell feststellen , warum etwas kaputt ist (insbesondere in Kombination mit der Bearbeitung von Live-Code). Oft kann ein visueller Test Probleme identifizieren, mit denen Sie ansonsten rechnen müssten , um mit Code zu testen, oder Probleme, bei denen es keine "richtige" Antwort gibt (z. B. Optimierung).

— Andrew Russell

Und die Idee, dass Komponententests "oft genug" durchgeführt werden müssen (wie in: immer auf automatisierte Weise), ist falsch. Code, der sich offensichtlich nicht ändert, muss nicht erneut getestet werden. Und wenn der Code wird geändert wird, soll der Entwickler die Änderungen dabei tun , während die entsprechenden verfügbaren Tests unter Verwendung von (visuell, Code-Basis oder auf andere Weise). Offensichtlich gibt es Code mit einem bestimmten Risikoprofil, bei dem ein automatisierter Test eine lohnende Zeitinvestition darstellt. Solche Szenarien sind jedoch in der Spieleentwicklung besonders selten.

— Andrew Russell