> On 30 Jan 2015, at 12:18, Ben Coman <b...@openinworld.com> wrote: > > 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
Actually the proper usage is MyTestCase run: #testSelector or MyTestCase debug: #testSelector > 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/ > >
