Extending Protean to generate sample test code compatible with existing test tools

[atulkpatel]

Chaps,

Finally free from my full time employment to brain dump some ideas for potentially enhancing protean.

So I'm from a testing background, I'm going to chat from a testers' perspective rather than a developer, so my first hurdle with protean is accepting this "new" technology
for validating my system-under-test (SUT). I've already got a SUT that I don't trust, so when things break who should I trust? Should I debug the SUT or the test tool? Why should I trust protean? Why should I learn to use another piece of tech when there are others available?

Every test tool has its pros & cons, and its more about using the right tech for the job, sometimes this means using several different tools to validate the SUT.

To help accelerate the adoption of Protean I felt it would be beneficial to be able to generate sample
test code that could be used in other widely adopted/mature test tools. to start with, I would suggest generating sample test code for JMeter, SoapUI. I would envisage sample code would be imported into these tools which would run tests out-of-the-box, but then expect the end user to enhance/extend the tests in that environment which they're already familiar with. Both JMeter and SoapUI can be used to exercise functional and non-functional features of a SUT, they're available on linux, MAC and Windows - so could target a wide audience.

I've so far seen Protean used with curl + XML/JSON payloads, which exercises each endpoint
individually. For System level testing you would potentially need to orchestrate / exercise different
end points, based on pass/fail results take alternative actions - which is where I think tools like
JMeter and SoapUI could be useful. From what I remember JMeter saves its tests scenarios as XML. I can't say if SoapUI has a suitable format for importing tests.

How we go about doing this, which existing tools we decide to support is another questions !
Any thoughts?

Atul.

[rossajmcd]

Hi Atul.

Thanks for the feedback/ideas.

We have plans to generate test code (we were going to have a go with clojure based test code to start). The idea of generating more data, to power tests with existing tools is better. We like data driven everything.

We do not have much experience with JMeter beyond load testing, but we know it is a popular choice, and so would be keen to explore this a little further with you, starting with some simple use cases perhaps ? Scratching an itch is usually the best way to go, so if you have anything in particular in mind let us know.

I understand sometimes it takes time etc to convert ideas into a non IP compromising example etc, so this may require some thought.

Cheers,

Ross.