Unittests for client code

[Andrew Melo]

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

[Jacob Wan]

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.

Just food for thought.

Jacob

> --
> You received this message because you are subscribed to the Google Groups
> "cherrypy-users" group.
> To post to this group, send email to cherryp...@googlegroups.com.
> To unsubscribe from this group, send email to
> cherrypy-user...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/cherrypy-users?hl=en.

[Eric Larson]

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.

HTH!

Eric

[0] http://pytest.org

[1] http://supervisord.org/

[2] http://ziade.org/2012/02/24/circus-a-process-controller/