I've got a JMeter test plan that I'm in the process of amending to use external property files for environment details and thread group numbers - similar to this link:
I've got this working on the command line. I can pass in paths to different property files for different environments and different thread numbers. I'm maintaining each environment in its own file (e.g. environmentA.properties and environmentB.properties). Same idea with the thread number configurations. First question - is this a sensible approach or should I store them all in 1 file? If so, how would I explicitly refer to 1 environment over the other (for example)?
I also still want to be able to use the GUI mode of JMeter (e.g. for adding/editing tests that are in progress). I've tried the property file reader config element that this link talks about (http://www.testautomationguru.com/jmeter-property-file-reader-a-custom-config-element/) and I've gotten this to work. Though I've had some trouble with user defined variables that need information from the property files. The user defined variables are acted on before the property files are read so the first run fails. I can get round this though.
My issue is that the property file reader element overwrites whatever I put in at the command line. For example, if I specify environmentB.properties at the command line but the property file reader states environmentA.properties then environmentA.properties is used.
Is there a better way to achieve what I'm after? I've briefly investigated a Groovy pre-processor script for loading the property files, which might work, though would I need to assign out every variable? I've seen a Beanshell equivalent that just uses props.load(<filename) which has potential. But again, I imagine this would overwrite command line arguments.
Hope the above is clear. Happy to add more detail if not.
I'm currently leaning towards using defaults in the parameterised environment/thread group details. So I'd pass in property files via command line but just use defaults in GUI.