Faster round-trip times: in-process SliM server? Or leaving it running? #314

Closed
raboof opened this Issue Sep 4, 2013 · 7 comments

Comments

Projects
None yet
3 participants
Contributor

raboof commented Sep 4, 2013

Having the SliM server in a separate process has a lot of advantages: it opens up the possibility of writing SliM servers in other languages, you can host a central SLIM server and talk to it from multiple clients, and it keeps the classpath of the SUT as clean as possible.

It also has disadvantages: in the common case of locally running a single test with a Java SUT, having to spawn a JVM introduces a considerable delay. The 'debug' FitNesse option starts the SliM server in-process, and I've seen tests go from 8 to 2 seconds by using that*.

Using the 'debug' option for anything else than debugging is not something you want to do, however, as the in-process SliM of course has a contaminated classpath. It does make me wonder, however, whether this could be tackled by using a separate classloader for the in-process SliM server. Also, it could be made even leaner by skipping the list serialization/deserialization steps.

Just throwing this out there, I'd like to explore what impact such an option might have, perhaps you have some additional insights.

  • Of course this is a one-time improvement per run, so it doesn't make a lot of difference when running a bigger suite, but it makes the round-trip when writing/maintaining a single test more pleasant.
Contributor

raboof commented Sep 4, 2013

Of course when using a separate classloader all SUT classes have to be loaded into that, too - that's still bound to produce some overhead.

Perhaps a better strategy for faster local round-trips might be to keep the SlimServer running, instead of spawning one for each test run?

Contributor

Kosta-Github commented Sep 4, 2013

I am using FitNesse for testing C++ code via my wrapping framework (https://github.com/AIM360/fitnesse-cppslim). For this to work it is required to support the external process functionality also in the future...

Contributor

raboof commented Sep 4, 2013

Yes, that should almost go without saying.
Op 4 sep. 2013 20:28 schreef "Kosta" notifications@github.com het
volgende:

I am using FitNesse for testing C++ code via my wrapping framework (
https://github.com/AIM360/fitnesse-cppslim). For this to work it is
required to support the external process functionality also in the future...


Reply to this email directly or view it on GitHubhttps://github.com/unclebob/fitnesse/issues/314#issuecomment-23812398
.

Collaborator

amolenaar commented Sep 4, 2013

The test system code has been refactored quite a bit. The last step is to be able to provide custom test system implementations. On the fun side: internal test systems already exist, but they're only used by the unit tests. Exposing those would solve the problem.

Contributor

raboof commented Sep 5, 2013

@amolenaar yeah I played around with that a bit ( https://github.com/raboof/fitnesse/tree/slim_internal ) - but there's a couple of challenges still (keeping the classpath clean (which is bound to produce additional overhead), capturing output, cleaning up after ourselves) - I'm starting to think keeping a SlimServer running might be more effective.

Collaborator

amolenaar commented Jan 11, 2014

FitNesse supports an in-process server (slim^inprocess) for Java. All dependencies, also the ones required to run the SUT should be on FitNesse's classpath.

Note that the main purpose of this test runner was to (unit) test fitnesse itself.

@amolenaar amolenaar closed this Jan 11, 2014

Contributor

raboof commented Jan 12, 2014

The other approach, keeping the slim server running, is now also possible, and I'm getting great results with that. I've written them down at http://blog.xebia.com/2014/01/06/speedy-fitnesse-development/ .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment