Run tests against out of process smart server

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?"

On 4 October 2011 23:11, John A Meinel <email address hidden> wrote:
> 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.

We could have the external process write to a log file, and then
attach that file to the test result, and truncate it after each test.

>
> 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 arrange for the server to run across the whole test
directory, and then to pass paths relative to that.