how to debug zinc server errors from tests
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/
Martin,
On 29 Jan 2015, at 06:23, Martin Bähr <mbaehr@email.archlab.tuwien.ac.at> 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?
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. 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. Sven
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/
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/
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 < mbaehr@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/
On 30 Jan 2015, at 12:18, Ben Coman <btc@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 <mbaehr@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/
On Sat, Jan 31, 2015 at 4:48 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 30 Jan 2015, at 12:18, Ben Coman <btc@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
Ahhh... Usually I do this when a test fails intermittently such that clicking on TestRunner's list of failed tests doesn't bring up a debugger. So my hack was to avoid the "on: self class failure , self class skip, self class warning, self class error do: [ ... ]" exception handling in #runCase:. #debug: is much better than my hack - thanks. cheers -ben
On 30 Jan 2015, at 10:11, Martin Bähr <mbaehr@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?
There could be something wrong with your test itself. Why don't you post what you are doing ?
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/
participants (3)
-
Ben Coman -
Martin Bähr -
Sven Van Caekenberghe