Run tests against out of process smart server
Bug #866111 reported by
Martin Packman
This bug affects 2 people
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Bazaar |
Confirmed
|
Medium
|
Unassigned |
Bug Description
Currently tests needing a smart server a test specific implementation up in a thread to run against, which is not a very realistic environment and is prone to test-only issues such as hangs. Instead, tests should use the real smart server, running in a separate process, which is more typical of actual usage and should be easier to manage when things go wrong.
By using testresources, which bug 866107 covers the introduction of, it should be possible to avoid needing to spawn a new process for every test and thereby minimise the overhead.
tags: | added: selftest |
Changed in bzr: | |
importance: | Undecided → Medium |
status: | New → Confirmed |
Changed in bzr: | |
assignee: | nobody → Martin Packman (gz) |
Changed in bzr: | |
assignee: | Martin Packman (gz) → nobody |
tags: | added: check-for-breezy |
To post a comment you must log in.
Sounds like a good idea. One thing that the current one does well is to get any exceptions from the smart server code and get them to be raised in the test suite, rather than just as stipple on stderr.
It would be nice to add this.
The other potentially difficult part is getting the current working dir playing nicely in the separate process, vs what the test suite expects. Especially since to prevent exposing content, we chroot the smart server process.
In the test suite, we use an internal api to say "it is ok for you to open up branches in this directory", but that isn't something we would want to expose on a generic server. If necessary we could expose it for just the test server.
We could do something like read stderr for exceptions, and re-raise them, etc.
However, we could also set up a test-suite manhole, so that we can pass in "allow this directory" requests, and also "were there any exceptions?"