jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robin D. Wilson" <rwils...@gmail.com>
Subject RE: For future JMeter enhancements... Folders for Thread Groups...
Date Thu, 02 Feb 2012 18:05:24 GMT
It does for me... I'm really into organization, and folders allow me to
'hide/show' various sections of my test plan quickly - in the GUI mode.
(Obviously, folders don't add a lot if you are running things from the
command line.)

For example, I have a test with 10 "thread groups" in it. The first 5 are
part of the test 'setup' functionality (e.g., they create the data needed by
the last 5 thread groups). It would be nice to have a folder called "data
setup" and another called "main test", each with its respective thread
groups. I would like to be able to select the "data setup" folder and
disable it - and run the "main test" separately, or vice versa - run the
data setup and not the main test.

I could certainly create 2 different test plans, and run them independently
- but when they are dependent on each other, it seems a little tedious to do
it that way.

For the record, my tests are fairly simple - the 5 thread groups in each of
the above sections merely include the same basic test controllers - but with
different configuration parameters. So in effect I have 2 actual 'test'
procedures, with 5 different configurations that I need to run for each
section of the test.

I'm just wishing I had the ability to organize my thread groups into
"units", so I could manage them as a whole unit within a test plan.

--
Robin D. Wilson
Sr. Director of Web Development
KingsIsle Entertainment, Inc.
VOICE: 512-777-1861
www.KingsIsle.com


-----Original Message-----
From: Bruce Ide [mailto:flyingrhenquest@gmail.com] 
Sent: Wednesday, February 01, 2012 6:35 PM
To: JMeter Users List
Subject: Re: For future JMeter enhancements... Folders for Thread Groups...

Does that really buy anything over having separate tests? It seems to me
that it would just increase clutter inside the test.

I've thought about implementing variable scope for include controllers
myself, but that leads you down the load of treating jmeter like a
programming language. That got me to thinking whether I really wanted to
treat jmeter as a programming language. It's kind of the same reason I don't
delve into adding expect/send samplers for ssh connections to the tool. It's
really not in-scope for what jmeter is good at. Sure, you could shoe-horn
that functionality in, but it just doesn't seem like a terribly good idea.

It seems to me that a best practice for jmeter is to keep your test small,
simple and focused on one piece of functionality. I've used it for pretty
complex functional testing of web applications, and the tests quickly become
very difficult to manage and maintain.

I'm really leaning toward just wanting a robust test library that I can
write tests in with a real programming language for a lot of the functional
testing I'm doing. It really wouldn't take a lot of polish around a cppunit
or junit framework to get me where I really want to be. But that's really
not in the same nieghborhood of jmeter, at all.

--
Bruce Ide
FlyingRhenquest@gmail.com


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
For additional commands, e-mail: user-help@jmeter.apache.org


Mime
View raw message