El miércoles, 15 de julio de 2015, 14:12:08 (UTC+2), Chris Angelico escribió: > 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
Thanks for your comments Chris. I've come back to the problem today after a few days on trip. Fortunately someone in other mailing list pointed me that the join method was hanging the main thread. Without this inconvenience I can focus on the exercise's main goal. Despite the impression that surely I gave, I'm quite familiar with programming and general bug hunting rules. The problem is that I'm inexperienced with Python and the subtle details of multiple threads ;) Thanks! -- https://mail.python.org/mailman/listinfo/python-list
