On 25 July 2011 13:05, _ext van Leeuwen, Paul <[email protected]> wrote: > Apparently I am not the only person who sees the benefit of a more > programmatic interface: I found that some other guy from some other company > already created a feature request some time ago: > https://issues.apache.org/bugzilla/show_bug.cgi?id=50034 > > I guess now I can only wait. If you read this thread and also want a more > programmer-friendly JMeter API, then please consider leaving a comment on the > issue above to make yourself heard.
Or better, provide a patch? > With regards to the suggestions made on this email-thread: > > @apc : it seems to me that your logic is from the point of view of JMeter. I > am looking at other frameworks: like when running a large regression test set > on the machine of every developer and some continues integration server (like > Hudson). Some of these tests might use JMeter while others do not. In such > case you just want to be able to add JMeter as a dependency on your project > (having e.g. maven managing the details) and do something like: > JMeter jmeter = new JMeter(); > TestResult result = jmeter.run(outputStreamWithMyJMXFile); I presume that is an inputStream ... > assertTrue(result.isSuccessfull()); There is no such class as TestResult - did you mean SampleResult? Or is this a new class? In any case, how is the success or otherwise determined when there are multiple samples? I.e. what do you expect the response to tell you? > Another example is when defining a broader set of automated tests in > FitNesse. Trying to write fixtures that call JMeter is currently quite a pain. > > @brian : you seem to understand what I mean and what I am trying to do. > Indeed there are solutions existing to call JMeter in a programmatic way: the > ant plugin you refer to assumes JMeter to be installed in a specific > location. There is also a maven plugin that has a lot of boilerplate code to > initialize JMeter. Both are a bit hacky and unstable on the long term: with > newer versions they may break. That is exactly why I would hope that JMeter > has a native API for its core (which could then be worked on from the GUI or > from other Java code. I am not sure whether the JMeter developers would > consider such. > > @deepak : sure I could decompile the JMeter plugin I was referring to and > move to a JMeter alternative that is more programmers friendly (like > HttpUnit), but how would JMeter benefit from that? Also I still find JMeter > the best tool for our needs: from time to time we will have to record new > test actions and the JMeter GUI is quite helpful there. Also JMeter is a tool > that is already known to the less-technical people in the department, so I'd > rather not switch. For a response to the second half of your message: please > see my response to apc above. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
