4

We have a moderately large collection of Java components (some using some JNI). Each launches as a daemon (or Windows service) using the Tanuki package. Some publish SOAP or REST endpoints, others take messages from JMS. Some talk to each other.

Each component reads an XML file for some configuration; they aren't (yet) coded to just come up and wait for someone to tell them what to do.

We're looking for a testing framework for system-level tests. Note that these things are not webapps (war files) that deploy in containers. When they need to offer an endpoint, they embed a container via Apache CXF. So cargo.codehaus.org does not look apposite.

We don't really care about the typical TDD focus on 'Test cases in English.' Everyone involved here is a programmer comfortable with typical programming languages and file formats; we really don't want or need the additional overhead of building and maintaining things that map English phrases to test cases.

We did have an experiment with the Robot Framework, but it didn't go very well. The 'English' aspect consumed a lot of time, and we had horrible problems simply managing the deployment of the framework itself. (I should mention that we use Maven as a build tool.)

What frameworks should we be looking at to script configuration, launch, and monitoring?

Improve this question
3
  • I assume all the configure, launch, and monitoring actions are performed over the wire, given what you said in the first paragraph. – user246 Oct 20 '11 at 19:08
  • Not yet. Edit to follow. – bmargulies Oct 20 '11 at 19:29
  • 1
    Do you already have client libraries for issuing SOAP, REST, and JMS requests? Or is that something you hope the test framework will provide? I want to narrow down what you have and what you need in order to configure, launch, and monitor. – user246 Oct 20 '11 at 23:54
3

For the SOAP endpoints, you might be able to use what this person did along with SoapUI.

It does SOAP/REST/JMS, and may also work for the other kind of endpoints (like the 'talking to each other' reference).

Hm. Re-re-reading the question, you also ask about config/launch/monitoring. I didn't really answer that, did I?

Given that you can get Jenkins to do anything, it might be reasonable to write scripts that Jenkins calls whenever a build is triggered. These scripts would do the deploy/configure/launch and maybe register the new service with whatever monitoring solution you have.

For a totally integrated solution (including running it in a cloud, so that you don't even have to worry about provisioning hardware), you might look at something like AppDynamics (although last I looked at the product, it didn't have a provision for driving tests, just managing/monitoring the environment).

Improve this answer
2
  • The link is dead in here. – bmargulies Nov 8 '12 at 11:19
  • I let the author know, but the whole site appears to be defunct. If I hear back, I'll update. Thanks! – Rob Fagen Nov 8 '12 at 16:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.