how to debug zinc server errors from tests

> On 29 Jan 2015, at 06:23, Martin Bähr <[hidden email]> wrote:
>
> hi,
>
> 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.
>
> next i get an opportunity to debug the test, but what i really want is to to
> debug the server itself.
>
> one way is to run the client request manually from the browser, while the real
> server is in debug mode. that works most of the time, but sometimes it doesn't
> because there is a difference between the test-server and the real server.
>
> i found that i can set the test server into debug mode too, but that is not
> very satisfying because it causes the test to hang and lock until a timeout is
> reached and only then the debugger pops up. i'd like the debugger pop up
> immediately, let me debug and fix the error, and then have the tests proceed.
>
> is there a way to do that?

> greetings, eMBee.
>
> --
> 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/
>

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

> and you can wrap that in a fork.
>
> cheers -ben
>
> On Fri, Jan 30, 2015 at 5:11 PM, Martin Bähr <[hidden email]> 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/
>
>

> On 30 Jan 2015, at 10:11, Martin Bähr <[hidden email]> 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/