jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <>
Subject Re: Coding JMeter tests
Date Fri, 14 Nov 2014 01:32:32 GMT
On 13 November 2014 12:54, Flavio Cysne <> wrote:
> My 2 cents.
> I really love JMeter and I'll try to get this passion aside from my opinion.
> 1. Developers are free to do whatever they can with JMeter.
> JMeter can test TCP, SOAP, JSF, .NET, common websites, Socket, Database
> Queries, WebSocket (not from the core, but there is a plugin for this) and
> many more (and even MycroStrategy flash reports. I made a script to test it
> using WebDriver).
> 2. JMeter gives you the opportunity to evolve itself by your hands (make a
> plugin)
> If there's a protocol you can't test because JMeter has no Sampler for it,
> do yours. It's not an excuse to be "unhappy" with JMeter. If there's a
> Sampler but it is not complete enough, fork it, do your upgrades and submit
> back to community.
> 3. Developers can do logic programming in JMeter test script.
> There are plenty of ways you can customize your script logic. The way you
> use Logic Controllers, and programmable Samplers like BeanShell Sampler, OS
> Process Sampler or BSF Sampler, is what you need to make it work.
> Free your mind!!!
> I've been using JMeter for performance tests since 4 years ago, and
> capturing 2 scripts, in average, every week for different test scenarios.
> Some of those scripts had a complex logic to fulfill (test workflow
> requirements). Sometimes I had to write down the logic and make tests using
> different JMeter components to know exactly what I had to use to achieve
> the test requirements.
> You have to understand how JMeter components interact to use them properly.
> About this link
> I use JMeter Ant task and took some tests with JMeter Maven Plugin. Ant
> task is more easily customized than Maven plugin. When I tested JMeter
> Maven plugin it was brandy new and have less documentation than now. I'll
> take a look again to know If I hadn't used its full potential.
> I can't say that JMeter has no cons, all tools have theirs.
> What I can say about that is JMeter source code is a bit tricky, but I've
> not dedicated enough time to understand it.


> My opinion is that JMeter GUI classes and classes used during non-GUI test
> execution should be taken apart so it could use less memory for non-GUI
> tests.

This is already the case.
The GUI is built from separate classes that are not loaded during
non-GUI test runs.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message