Noob in Python. Problem with fairly simple test case

[Jason P.]

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. <suscricions at 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!