If there is a particular test you want to run outside of the test framework, essentially you reproduce TestCase>>runCase in the Workspace. For example... MyClassTest new setUp testMyTest
and you can wrap that in a fork. cheers -ben On Fri, Jan 30, 2015 at 5:11 PM, Martin Bähr < mba...@email.archlab.tuwien.ac.at> wrote: > Excerpts from Sven Van Caekenberghe's message of 2015-01-30 07:59:00 +0100: > > > when debugging a zinc server with tests structured as in > > > http://zn.stfx.eu/zn/build-and-deploy-1st-webapp/ > > > i am wondering how to best debug errors in the server while running > tests. > > > > > > one test makes a ZnClient connection to a testserver started from the > same test. > > > the test fails with the server returning a 500 error. > > Writing a unit test using both an HTTP client and server is already a bit > > tricky sometimes, having it fail is always ugly. This is more a threading > > issue than anything else. > > > > I usually will do as you describe: rerun manually with a server where > debug is enabled. > > ok, unfortunately i now am facing an issue that i can not reproduce > manually. i > suspect that is because of a difference between the test server (started in > withServerDo:) and my actual server. > > i could probably set up a clean image and retry it there. > how can i avoid that and run a clean server instance manually in my dev > image? > > > It could be an idea to try to improve the situation, but it won't be > easy. To > > enable a debug/continue style the client request should first not time > out > > (which is not a good idea for unattended tests), then something should be > > done about the UI thread. > > well, i am glad they time out, otherwise i believe the image would be > locked up. > the timeout should be paused though while the debugger is running. > > so the problem is really that the test would need to run in a separate > thread > so as to not block the UI? but to do this, the whole test-running framework > would have to be changed, and it's not something i can do in the test code? > > what about a hack to instead make a shorter timeout? let the test fail > immediately, then the UI can bring up the debugger, i can inspect the > issue, > fix it and rerun the test? > > greetings, martin. > > -- > eKita - the online platform for your entire academic > life > -- > chief engineer > eKita.co > pike programmer pike.lysator.liu.se caudium.net > societyserver.org > secretary > beijinglug.org > mentor > fossasia.org > foresight developer foresightlinux.org > realss.com > unix sysadmin > Martin Bähr working in china > http://societyserver.org/mbaehr/ > >