We have an application that contains both server (written in cherrypy) code and client code that queries the server (i.e. different components on different machines communicate over REST), but our unittest harness is a) somewhat flaky (transient connection errors) b) somewhat innacurate because cherrypy is running in the same process as the client code (though in a different thread).
Does someone have an example for robustly starting/stopping a cherrypy server in a separate process and doing the proper synchronization to keep the client from attempting to connect before the server has finished acquiring the socket and starting up?
I saw the code in the cherrypy test tree, but it appears it starts the server in the same process.
While i don't have an answer to the exact question regarding client and server code synchronization, I thought I'd give my two cents for what it's worth. If it's not helpful, then please forgive the intrusion.
Unless there's some specific need to exercise the server code by making full-fledged HTTP requests against it, you could rewrite your unit tests to call your own server code directly, and use a mocking framework like Michael Foord's Mock (http://www.voidspace.org.uk/python/mock/) or pymox (http://code.google.com/p/pymox/) to mock away other services and library calls that would normally only make sense at runtime. This should encourage individual unit tests that are smaller, more numerous, more granular, and more highly focused on testing your own production code. Also easier to maintain, less brittle, yadda, yadda.
Client-side testing could be moved into its own projects (perhaps using Selenium, jsTestDriver, etc.), completely independent of the web application and CherryPy. Together with your server-side unit tests and confidence in CherryPy's own unit tests, you'd have complete code coverage, with one-to-one coupling of unit test projects to production components, which should make the whole system very flexible.
On Thu, Apr 19, 2012 at 2:43 AM, Andrew Melo <andrew.m...@gmail.com> wrote: > Hello, everyone-
> We have an application that contains both server (written in cherrypy) code > and client code that queries the server (i.e. different components on > different machines communicate over REST), but our unittest harness is a) > somewhat flaky (transient connection errors) b) somewhat innacurate because > cherrypy is running in the same process as the client code (though in a > different thread).
> Does someone have an example for robustly starting/stopping a cherrypy > server in a separate process and doing the proper synchronization to keep > the client from attempting to connect before the server has finished > acquiring the socket and starting up?
> I saw the code in the cherrypy test tree, but it appears it starts the > server in the same process.
> Thanks, > Andrew
> -- > -- > Andrew Melo
> -- > You received this message because you are subscribed to the Google Groups > "cherrypy-users" group. > To post to this group, send email to cherrypy-users@googlegroups.com. > To unsubscribe from this group, send email to > cherrypy-users+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/cherrypy-users?hl=en.
> We have an application that contains both server (written in cherrypy) code and client code that queries the server (i.e. different components on different machines communicate over REST), but our unittest harness is a) somewhat flaky (transient connection errors) b) somewhat innacurate because cherrypy is running in the same process as the client code (though in a different thread).
> Does someone have an example for robustly starting/stopping a cherrypy server in a separate process and doing the proper synchronization to keep the client from attempting to connect before the server has finished acquiring the socket and starting up?
> I saw the code in the cherrypy test tree, but it appears it starts the server in the same process.
> Thanks, > Andrew
I'm not sure what test runner you are using, but we use py.test[0] and do something similar. It starts up databases and external services as well as the services we want tested. With py.test we've configured a ServiceManager object that you can register services with. Each service type is its own object that has a start/stop method. The service manager will block and make sure the service is up based on whatever the service has defined. Each service is started in its own process.
We copied the "wait_for_occupied_port" from CherryPy. We also usually built a /_status/ endpoint into most services that respond once the service is up. For example, if you have some database like service that needs to warm up a cache, the port is occupied rather quickly, but the /_status/ URL won't respond with a 200 until the cache has been warmed up.
We made the service manager available from the py.test namespace. This means that in the tests that need a service we can write a setup function that uses the py.test.service_manager to start the necessary service. If the service has already been started, it won't start it again. I'd share the code, but it is somewhat specific to some of our internal apps. I'm sure that you could build something similar allowing another tool like supervisord[1] or circus[2] to handle the process management.
> -- > You received this message because you are subscribed to the Google Groups "cherrypy-users" group. > To post to this group, send email to cherrypy-users@googlegroups.com. > To unsubscribe from this group, send email to cherrypy-users+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/cherrypy-users?hl=en.
