I'm trying to transfer parameter from RawRequest using SoapUI but when reading it, value changes.
The parameter is request ID (which is unique for every test), it is requested by every test case from Custom Properties, where it is stored as follows:
${=((System.currentTimeMillis().toString()).subSequence(4, (System.currentTimeMillis().toString()).length())).replaceFirst("0", "")}
Above generates number like this for example:17879164.
The problem starts, when I'm trying to transfer it using either in build in feature or Groovy script. Both read parameter incorrectly:
Following is how the parameter presents in RawRequest window:
This is how it is read in Transfer window in SoapUI:
And finally, how it is read by Groovy script:
Can any one explain, why this value despite being shown in SoapUI RawRequest window as 17879164 is then read as 17879178 using two different methods?
I think the clue might be, that when I'm using "flat number" as reqId and not the generated one, both methods work fine and return correct number. But in this case when it is RawRequest, I understand that it is set once and for all, so what is show in the window and what is being read, should be the same.
What you are seeing is a "feature" in SoapUI. Your transfer step will transfer the code, which will then get evaluated again, resulting in a different value.
What you need to do is:
Create a test case property.
Set the property from test case setup script to a value. So in your case, something like testCase.setPropertyValue("your_property", ((System.currentTimeMillis().toString()).subSequence(4, (System.currentTimeMillis().toString()).length())).replaceFirst("0", ""))
Anywhere in your test refer to the test case property ${#TestCase#your_property}... which is a fixed value at this point, so will be always the same.
Related
I need a little help with a process we're trying to build that should be able to react dynamically.
The process goes a little something like this.
User will submit a process request against an environment, submitting an array of string values as a runtime value. The process will take these in, as an array in bash, and loop through them, checking them against a predefined string list for validity. Upon finding they are valid, reacting differently based off of which values are in the string.
Example:
User submits a process request with values "abc", "bcd", "cde", "def"
Values "abc", "bcd", and "def" are valid.
We do a bit of manipulation to make them usable:
echo ${p:inputArray}
inputArray="${p:inputArray}"
inputArray=${inputArray//]/}
inputArray=${inputArray//[/}
inputArray=${inputArray//,/}
inputArray=( "${inputArray[#],,}" )
Then loop through each value and react:
for inputValue in $inputArray; do
if [[ "${validInputArray[#]}" =~ "${inputValue}" ]]; then
// Check if value is the outlier case "A"
// Or if the value is normal (but multiple) case "B"
// If case "B" then we'll build a variable for it
// It should be something like ${p:environment/$inputValue.action}
This, ideally, would give me the value of ${p:environment/abc.action} for example. But it does not. It gives me a string. I have no way to evaluate the dynamically created property request, as all properties are evaluated at initialization and not on the fly.
We can handle it via a "case" method - but it's a bit ugly, and will only get uglier as our number of valid inputs grow.
Instead of sending it an array of values, you can configure UCD to prompt them for specific values. You can do this on the application process. That way, when the user kicks off the deployment, there is no guessing on the validity of the input.
On the process page of the application, click on the Application Process Properties link
From there, you can configure it to require a certain pattern (checked via regex), or explicit values from a drop down, raw text, dateTime, etc. Here, I've configured a property with a multi-select to allow specific JVM maximum heap values. By limiting this to specific values, you can avoid typos and failed deployments.
Once configured, when you launch your process, you are presented with the property in the interface:
I have a Test Plan containing one Thread Group whith one HttpRequest sampler, JRS223PreProcessor and one csv data set config. I need to read from csv, at run time,the current value of column 2 and use it in my JSR223 PreProcessor. In order to do this, I defined a variable on Test Plan:
name ${__CSVRead(C:/Users/marial/Desktop/csvs/csv_hotelCodeReq.txt,2)
In JSR223 PreProcessor I am taking it like this:
String name= new String(vars.get("name"));
I would expect this value to change on each line readed, but it didn't, it always take the first value encountered. Does anyone know why?
To be more specific, if I have the csv file :
1,2,firstName1:lastName1
3,2,firstName2:lastName2
and loop count = 2, users=1 than the values of name are:
loop1: firstName1:lastName1
loop2: firstName1:lastName1
The other values are correctly handled, so it goes to the next line.
According to User Defined Variables documentation:
Note that all the UDV elements in a test plan - no matter where they are - are processed at the start.
So your __CSVRead() function is evaluated only during test startup and only once
The solution would be moving the function into "Parameters" section of the JSR223 PreProcessor and you will be able to access the function output as Parameters in your Groovy script like:
String name = Parameters
Demo:
This way the __CSVRead() function will be executed each time the JSR223 PreProcessor is called. Check out Apache Groovy - Why and How You Should Use It article to learn more about Groovy scripting in JMeter
I have test cases defined in an Excel sheet. I am reading a string from this sheet (my expected result) and comparing it to a result I read from a database (my actual result). I then use AssertEquals(expectedResult, actualResult) which prints any errors to a log file (i'm using log4j), e.g. I get java.lang.AssertionError: Different output expected:<10> but was:<7> as a result.
I now need to write that result into the Excel sheet (the one that defines the test cases). If only AssertEquals returned String, with the AssertionError text that would be great, as I could just write that immediately to my Excel sheet. Since it returns void though I got stuck.
Is there a way I could read the AssertionError without parsing the log file?
Thanks.
I think you're using junit incorrectly here. THis is why
assertEquals not AssertEquals ( ;) )
you shouldnt need to log. You should just let the assertions do their job. If it's all green then you're good and you dont need to check a log. If you get blue or red (eclipse colours :)) then you have problems to look at. Blue is failure which means that your assertions are wrong. For example you get 7 but expect 10. Red means error. You have a null pointer or some other exception that is throwing while you are running
You should need to read from an excel file or databse for the unit tests. If you really need to coordinate with other systems then you should try and stub or mock them. With the unit test you should work on trying to testing the method in code
if you are bootstrapping on JUnit to try and compare an excel sheet and database then I would ust export the table in excel as well and then just do a comparison in excel between columns
Reading from/writing to files is not really what tests should be doing. The input for the tests should be defined in the test, not in the external file which can change - this can either introduce false negatives or even worse false positives (making your tests effectively useless while also giving false confidence that everything is ok because tests are green).
Given your comment (a loop with 10k different parameters coming from file), I would recommend converting this excel file into JUnit Parameterized test. You may want to put the array definition in another class, because 10k lines is quite a lot.
If it is some corporate bureaucracy, and you need to have this excel file, then it makes sense to not write a classic "test". I would recommend just a main method that does the job - reads the file, runs the code, checks the output using simple if (output.equals(expected)) and then writes back to file.
Wrap your AssertEquals(expectedResult, actualResult) with try catch
in catch
catch(AssertionError e){
//deal with e.getMessage or etc.
}
But it not good idea for some reasons, I guess.
And try google something like soft assert
Documentation on assertEquals is pretty clear on what the method does:
Asserts that two objects are equal. If they are not, an AssertionError
without a message is thrown.
You need to wrap the assertion with try-catch block and in the exception handling do Your logging. You will need to make Your own message using the information from the specific test case, but this what You asked for.
Note:
If expected and actual are null, they are considered equal.
This is driving me potty.
I'm trying to pass two SSIS variables to a command line executable using an Execute Process Task object.
No matter what I try, the values are not being passed through.
This is how it is set currently:
The variables are in scope and are of type string (representing integer values).
Sods law came into effect after posting this question. I tried evaluating my variables as an expression and assigning the resulting string to the arguments property.
I don't see why this would work over the example I gave, but it does, so I'm using that.
I have three dropdown boxes on a Main_Form. I will add the chosen content into three fields on the form, Form_Applications.
These three lines are added :
Form_Applications.Classification = Form_Main_Form.Combo43.Value
Form_Applications.Countryname_Cluster = Form_Main_Form.Combo56.Value
Form_Applications.Application = Form_Main_Form.Combo64.Value
The first two work perfectly but the last one gives error code 438!
I can enter in the immediate window :
Form_Applications.Classification = "what ever"
Form_Applications.Countryname_Cluster = "what ever"
but not for the third line. Then, after enter, the Object doesn't support this property or method error appears.
I didn't expect this error as I do exactly the same as in the first two lines.
Can you please help or do you need more info ?
In VBA Application is a special word and should not be used to address fields.
FormName.Application will return an object that points to the application instance that is running that form as opposed to an object within that form.
From the Application object you can do all sorts of other things such as executing external programs and other application level stuff like saving files/
Rename your Application field to something else, perhaps ApplicationCombo and change your line of code to match the new name. After doing this the code should execute as you expect.
Form_Applications.Application is referring to the application itself. It is not a field, so therefore it is not assignable (at least with a string).
You really haven't provided enough code to draw any real conclusions though. But looking at what you have posted, you definitely need to rethink your approach.
It's to say definitely but you are not doing the same. It looks like you are reading a ComboBox value the same (I will assume Combo64 is the same as 43 and 56) but my guess is that what you are assigning that value to is the problem:
Form_Applications.Application =
Application is not assignable. Is there another field you meant to use there?