On Wed, Jul 15, 2015 at 9:44 PM, Jason P. <suscrici...@gmail.com> wrote:
> I can't understand very well what's happening. It seems that the main thread
> gets blocked listening to the web server. My intent was to spawn another
> process for the server independent of the test. Obviously I'm doing something
> wrong. I've made several guesses commenting pieces of code (tearDown method
> for example) but I didn't manage to solve the problem(s).
>
When you find yourself making guesses to try to figure out what's
going on, here are two general tips:
1) Cut out as many pieces as you can. Test one small thing at a time.
2) If In Doubt, Print It Out! Stick print() calls into the code at key
places, displaying the values of parameters or the results of
intermediate calculations - or just saying "Hi, I'm still here and I'm
running!".
For #1, I would recommend first just trying to get the web service
going. Can you connect (using an external program) on port 8000 and
receive a text/plain HTTP response saying "Hello World!"? Never mind
about the test for the moment.
And for #2, judicious placement of console output will help you figure
out things you're not sure about. For instance, you're suspecting that
the main thread is getting blocked handling the web server. Easy way
to check:
def setUp(self):
# Start the forecast server
self.server = ForecastServer()
self.server.start(webservice.app)
Just before you construct the server, print something out. After
you've constructed it but before you call start(), print something
out. And after starting it, print something out. Then run the program.
If you see the first line and no other, then it's blocking during the
construction. Other deductions I'm sure you can figure out.
One small point: Probe even things that you think are trivial. In the
above example, I cannot see any reason why constructing
ForecastServer() could possibly block, because its init does nothing
but set a flag. But you can get surprised by things sometimes - maybe
the problem is actually that you're not running the code you think you
are, but there's some other ForecastServer kicking in, and it's
synchronous rather than subprocess-based.
End-to-end testing is all very well, but when something goes wrong,
the key is to break the program down into smaller parts. Otherwise,
all you have is "it doesn't work", which is one of the most useless
error reports ever. If someone comes to python-list saying "it doesn't
work", we'll be asking him/her to give a lot more details; if your
aunt asks you for help printing out a document because "it doesn't
work", you'll probably have to go over and watch her attempt it; and
it's the same with your test cases - you make them tell you more
details.
Hope that helps! The techniques I'm offering are completely
problem-independent, and even language-independent. IIDPIO debugging
works in anything that gives you a console, which is pretty much
everything - maybe it won't be print() but logging.debug(), but the
same technique works.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
