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/
>
>
