I'm trying to evaluate a not equals in a if condition in bean shell but though the logic seems to be correct. I'm not getting the expected results.
This is for bean shell post processor in jmeter
r = ctx.getPreviousResult().getResponseCode();
if (!r.equals(200))
{
log.info("vin IS --> "+"${vin}");
p.println(r +","+ "${vin}" + ",");
}
I'm intending to print only non 200 response code but it prints 200 response codes too.
thanks in advance for your help
The code :
if (!r.equals(200))
Should be:
if (!r.equals("200"))
And by the way, you should not use Beanshell anymore, prefer JSR223 Test Elements + Groovy as per this :
https://www.ubik-ingenierie.com/blog/jmeter_performance_tuning_tips/
You're comparing a String with an Integer, you need to either cast it to the Integer first like:
r = Integer.parseInt(ctx.getPreviousResult().getResponseCode());
You're using Beanshell which is a some form of performance anti-pattern. It's recommended to use JSR223 Test Elements and Groovy language for any form of scripting as Groovy has much better performance comparing to Beanshell.
You're inlining JMeter Variables into scripts, it is not very safe as variables might resolve into something which cause compilation failure or unexpected behavior. Moreover in case of Groovy variables will either be resolved only once or clash with GString templates / compilation caching feature. So consider changing:
log.info("vin IS --> "+"${vin}");
to
log.info("vin IS --> "+vars.get("vin"));
Related
If I use a JSR223 Preprocessor with the following code:
log.info("" + ${rand});
where ${rand} is a random variable, how can I make this variable change every time I loop this thread?
Changing the number of threads will indeed have the variable change each run, with loop it just takes one value and keeps it for all the other loops.
Putting it in a JSR223 Sampler yields the same result. I basically want the code to behave as a User Parameter.
Don't inline JMeter Functions or Variables in JSR223 Test Elements because:
They may resolve into something which will cause compilation failure
The syntax conflicts with Groovy's GStrings feature
If you tick Cache compiled script if available box the first occurrence will be cached and used on subsequent iterations, if you don't - you will loose performance benefits of Groovy
When using this feature, ensure your script code does not use JMeter variables or JMeter function calls directly in script code as caching would only cache first replacement. Instead use script parameters.
So:
Either move your ${rand} variable to "Parameters" section and change your code to
log.info("" + Parameters);
or use vars shorthand to JMeterVariables class instance, in this case change your code like:
log.info("" + vars.get("rand"));
You need to use vars to avoid getting cached/same value
vars.get("rand")
See JSR223 Best practices
script does not use any variable using ${varName} as caching would take only first value of ${varName.. Instead use vars.get("varName")
Using community soapui 5.2.1.
Can I use an XPATH assertion to test a number is between two values?
This question shows how to do one logical test.
But I'd like to store the value in a variable and test on an AND condition.
Something like (psuedo code):
declare namespace ns1='http://my.space/XML/output/6.1';
testme=//ns1:items-section[1]/ns1:results/#total_items;
testme > 100 && testme < 200;
If this can't be done, options i see are:
retrieving the attribute twice (guess that's not performant)
reverting to script assertion (more complex )
buy NG PRO ( more expensive)
IMO generally if you want to apply a pseudo code for assertion purpose I prefer to use script assertion since in SOAPUI Groovy script assertion gives you a lot of flexibility.
However your case seems short, and you're only worried about to avoid perform twice the same XPath; then you can use a option which is not in your list: XQuery Match assertion. The XQuery expression could be:
declare namespace ns1='http://my.space/XML/output/6.1';
declare variable $testme := //ns1:items-section[1]/ns1:results/#total_items;
($testme > 100 and $testme < 200)
Note the use of and instead of &&.
Also you can simplify your XPath expression using * for namespaces:
declare variable $testme := //*:items-section[1]/*:results/#total_items;
($testme > 100 and $testme < 200)
This will return in the expected result:
<xml-fragment>true</xml-fragment> or <xml-fragment>false</xml-fragment> depends on the $testme value.
Hope this helps,
What is the difference between the following lines of (rspec) code and regardless if they are the same or different, when should you use one instead of the other?
book = double("book")
allow(book).to receive(:title) { "The RSpec Book" }
versus
book = double("book")
book.stub(:title).and_return("The RSpec Book")
There are 2 differences but the result is exactly the same. Both are in regards to the rspec mocks/expectations syntax.
Use of #allow instead of #stub method. First case uses the new rspec syntax introduced this year. This is now the preferred way of using rspec. Altough the old syntax isn't deprecated, it will probably be disabled by default in rspec3. More info on this topic from the maintainer of rspec:
http://myronmars.to/n/dev-blog/2012/06/rspecs-new-expectation-syntax
http://myronmars.to/n/dev-blog/2013/07/the-plan-for-rspec-3
Use of block instead of #and_return to define the returning value. This has nothing to do with the mentioned syntax change; both approaches have been available for quite a while (since rspec 1). It is more appropriate to use the #and_return method, since it is (a) the default way, (b) more readable and (c) comes without any runtime overhead. The second approach using block is usually reserved to the corner cases, when you wish to return something of more dynamic nature - not a constant, but some kind of calculation.
The answer to your question would be to use combination of both:
use the #allow instead of #stub
use #and_return instead of block, unless you need to return dynamically calculated value
E.g.:
book = double('book')
allow(book).to receive(:title).and_return('The RSpec Book')
I'm a little confused concerning when to use ${...} compared to #{...}. Spring's documentation only uses #{...}, but there are plenty of examples that use ${...}. Furthermore, when I started with SpEL I was told to use ${...} and it works fine.
For those who are confused, an example of how I use it would be
#Component
public class ProxyConfiguration {
#Value("${proxy.host}")
private String host;
#Value("${proxy.port}")
private String port;
:
}
and some property file:
proxy.host=myproxy.host
proxy.port=8000
My questions are:
what are the differences or is it the same?
is one version deprecated so I should use the other one?
${...} is the property placeholder syntax. It can only be used to dereference properties.
#{...} is SpEL syntax, which is far more capable and complex. It can also handle property placeholders, and a lot more besides.
Both are valid, and neither is deprecated.
${expr} --> Immediate Evaluation
#{expr} --> Deferred Evaluation
Immediate evaluation means that the expression is evaluated and the result returned as soon as the page is first rendered. Deferred evaluation means that the technology using the expression language can use its own machinery to evaluate the expression sometime later during the page’s lifecycle, whenever it is appropriate to do so.
Complete reference here
There is no JSP EL, JSP uses SpEL. SpEL fits to technology that is using it.
Try reading this article, which suggests
"If the hash is used, your code is recomputed every time that element is included in a partial refresh (i.e. each time it is rendered). If you use a dollar, your code is only computed when the page is initially loaded. But this has been extended beyond just EL, to SSJS too. After the hash or dollar, the curly braces denote the start and end of your language. This will be important when we come to combining languages later."
Expression Language Specification • Final Release - May 8, 2006
Page 2:
An eval-expression is formed by using the constructs ${expr} or #{expr}. Both
constructs are parsed and evaluated in exactly the same way by the EL, even though
they might carry different meanings in the technology that is using the EL.
Do you prefer literal values or expressions in your Asserts in your unit tests? This little example demonstrates what I mean - please pay attention to the comments:
[Test]
public function fromXML_works() : void {
var slideshow : Slideshow = SlideshowConverter.fromXML(xmlSample);
// do you prefer literal value "1":
assertEquals(slideshow.id, "1");
// ... or an expression like this:
assertEquals(slideshow.id, xmlSample.#id);
}
private var xmlSample : XML =
<slideshow id="1">
<someOtherTags />
</slideshow>;
The nice thing about the expression is that when the XML sample changes, the unit test will not break. On the other hand, I've basically provided an implementation of one aspect of my SlideshowConverter directly in my unit test which I don't like (the test should test intent, not implementation). I can also imagine that tests using expressions will be more prone to programming errors (I could have, for example, made a mistake in my E4X expression in my test method).
What approach do you prefer? What advantage is usually more important on real world projects?
Particularly since you've tagged this TDD: stick with literals. Writing a test before code exists to pass it, you say to yourself, "Self: if I had this function and gave it those parameters, then this is what I would get back." Where this is a very specific value. Don't hide it away; don't abstract it - just put the value into the test. It enhances the documentation value of the test as well.
Personally, I like to use constants within my tests - it ensures that the test fixtures are simple and straightforward. Plus, as you mention, it avoids programming errors in the test itself, which may hide programming errors in the real code.