Martin Krieger

Führt man Tests in FitNesse aus, dann wird gelegentlich auch der Wunsch aufkommen, diese zu debuggen. Das Problem dabei ist, daß die Tests jeweils separate, vom FitNesse Server gestartete, Prozesse sind. FitNesse selbst unter einem Debugger zu starten nutzt daher wenig. Der dokumentierte Weg ist es, die Tests über separate Komandozeilentools unter einem Debugger aufzurufen und die Ausgabe in einer Datei zu speichern. Es geht aber auch anders:

Java

Unter Java wird das Debuggen aktiviert, in dem man beim Aufruf der VM die Option -agentlib:jdwp= nebst allerlei Parametern angibt. Dann kann sich der Debugger über TCP/IP, also auch an einem entfernten Rechner, und andere Protokolle mit der VM verbinden. Es ist sowohl möglich, daß der Debugger das zu debuggende Programm aufruft, als auch umgekehrt.

Da FitNesse den Aufruf der Java VM in COMMAND_PATTERN speichert, ist es beispielsweise mit !define COMMAND_PATTERN {java -agentlib:jdwp=transport=dt_socket,address=12345,server=y,suspend=y -cp %p %m} möglich, den Test im Debugmodus zu starten und auf das Verbinden des Debuggers zu warten. (Natürlich sollte man das nur in eigenen Dateien bzw. einem eigenen virtuellen Verzeichnis machen…) In den Entwicklungsumgebungen (ich verwende NetBeans, jede andere sollte das aber auch können) gibt es eine Funktion um den Debugger zu verbinden (Debug/Attach Debugger). Setzt man vorher noch einen geeigneten Breakpoint, so kann man ab dort dann debuggen.

.NET

Das .NET Debugsystem ist nicht ganz so vielfältig. Es ist -soweit mir bekannt- nicht möglich, ein Programm zu starten und es auf den Debugger warten zu lassen. Debuggen funktioniert nur lokal, es sei denn man hat den Remote Debugging Monitor auf dem entfernten System installiert. Dafür ist es jedoch möglich, den Debugger mit beliebigen laufenden .NET Prozessen zu verbinden, ohne das beim Starten dazu spezielle Optionen angegeben werden müssen.

Zudem kann ein .NET Programm erkennen, ob es mit einem Debugger verbunden ist (Debugger.IsAttached). Ich habe daher DotNetProxy.exe noch um eine Parameter -d ergänzt, der mit dem Aufruf des Testsystems wartet, bis ein Debugger verbunden (Debug/Attach to Process) wurde.

!define COMMAND_PATTERN {dotnet\DotNetProxy.exe -d %m %p}

dotnetproxy11.zip