We would like to test the following flow using Canoo. The tests are written in Groovy, and not as Ant tasks.
Send a request to a specific URL (we use "invoke")
Extract specific information from the response (we use "storeRegEx" with property:"ans")
Print the extracted value (for debug purposes). println "${ans}" - does not work
Use the extracted value in the next action (e.g. invoke "new/url/id=#{ans}")
We saw some references to using an AntBuilder, it fails as well.
Is there some example for that flow?
Thanks
remember that it depends on the ant property type (dynamic or ant) whether you have to use #{ans} or ${ans}
println will not work in webtests. Use the description property of webtest steps instead:
group(description:"#{ans}") {
...
}
this will show you the value of your property in the test result.
Related
I am trying to use Testrail as a test case management system and so,
integrating testrail with the Jenkins would be useful.
This is what I want to achieve:
Lets say I manually create three test cases in testrail with case ID's
C1, C2 and C3 and these test cases will have some unique automated test names such as A1, A2, and A3 (in more info, there will be a field in testrail with such a unique
information)
When I hit "Start Automated Tests" button and run a Jenkins job from testrail (considering I have already implemented UI script for testrail that has this button):
, I want to run a script/something that takes the case ID's of the selected test cases and annotate those IDs to the actual Java tests temporarily so that it can run those specific tests and post results back to the Testrail.
Approach I can think of:
When I hit "Start Automated Tests" button on Testrail, I can make a script to run to create an XML file that will include the desired selected test cases from Testrail. This XML will then be provided as a default input to the Jenkins job and it will run the test cases mentioned in the XML file. This XML will be temporary and will be replaced everytime the selection is made from the Testrail. However, how do you do it? I am a newbie to the Testrail and read its API and looks like API will be useful to post the results back to the Testrail. But, how do we achieve the mapping of the ID's?
Also, any advise on posting results back to the Testrail will be useful.
This isn't TestNG specific, but you can make a custom annotation in java. You can update a TestRail test in a test run through the api either by the test ID (using add_result), or both the case id and run id(using add_result_for_case). http://docs.gurock.com/testrail-api2/reference-results
The case id doesn't ever change, so you can just hard code these in your tests.
Here is what I'm using for this purpose:
#Retention(RetentionPolicy.RUNTIME)
#Target(ElementType.METHOD)
public #interface TestData
{
int testId() default 0;
String[] tags() default "";
}
My test method then looks like this(Using Junit, but shouldn't be much different with other frameworks):
#Test
#TestData(
testId = 177,
tags = {"smoke", "authentication"}
)
public void testName()
{
//Do the test
}
I then use a JUnit specific way to get the test method name to use in my teardown method, but I'm sure there is a variety of ways to do that. Once you have the test method name here is how I read the annotation:
#After
public void baseTearDown() throws Exception
{
//Good place to record test results
Method testMethod = getClass().getMethod(testName);
if(testMethod.isAnnotationPresent(TestData.class))
{
TestData testData = testMethod.getAnnotation(TestData.class);
//Do something with testData.testId();
System.out.println("Test ID = " + testData.testId());
}
//other cleanups
}
This mkyong link gives some pretty basic examples of both creating an annotation and reading it with reflection. This is what I used to get started:
https://www.mkyong.com/java/java-custom-annotations-example/
If you're starting the test run in your code, then you can just keep track of the test run id and use it as needed. If not, my preference is to define and set some environment variables using Jenkins or other scripts that your code can read from so you don't have to deal with passing around files for some really basic key value pairs
I'd like to write tests that would test behavior of externalized configs and assert that what gets set is what I expect. This is for the specific case where something like this is done:
Config.groovy:
a.reused.value = 'orig'
my.variable = '${a.reused.value}'
Externalized groovy file:
a.reused.value = 'new_value'
I expect that both a.reused.value and my.variable would be 'new_value'.
Now, I think I could have my unit test read in strings representing these config files (I do similar things for other unit tests to populate Holders.grailsApplication.config, for example), utilizing perhaps merge?
But what I cannot figure out is how to get the value that Grails actually gets during application run time. Instead, I get "${a.reused.value}" in my unit tests.
Is there a way to mimic this behavior of what Grails does of actually resolving this value? I did some digging around in Grails 2.4.4 source (which is what we are using) and didn't have any luck in figuring this part out. I also did try Eval.me(), but that doesn't seem to be quite right either.
While setting my.variable, you are not using a GString object, causing the expression to be treated as a value itself. Use double quotes to resolve expression automatically.
a.reused.value = 'orig' my.variable = "${a.reused.value}"
Update 1:
What you want to do is directly not possible. You are assigning the value to a variable from an expression. During evaluation of the config object for the first time, my.variable has been assigned a value, and now it doesn't contain an expression any more. So you have two options: 1) either reassign the second variable in external config also or 2) use a closure to assign the value to second variable.
my.variable = { -> "$a.reused.value" }
and while accessing do: grailsApplication.config.my.variable.call()
But again, in your code, you would have to be sure that this variable contains a closure not a value itself.
I would like to run a Concordion spec using a parameter. What I'd like to do is execute the spec using concordion:run. A little research pointed me to the existence of a concordion:params attribute, but I cannot find any documentation or examples.
I'm not sure how these two commands fit together; should the params element be nested inside the run element or outside? What is the value to fill in concordion:params="?" Where do I specify the param values themselves--in a concordion:set call?
concordion:params is an attribute to be used on the same element as the concordion:run attribute.
For example, in MyIndex.html:
<a concordion:run="concordion" concordion:params="foo=5" href="MySpec.html">My Spec</a>
with the fixture class:
#RunWith(ConcordionRunner.class)
#FullOGNL
public class MyIndex {
public void setFoo(Integer foo) {
System.out.println("foo = " + foo);
}
}
Note that the #FullOGNL attribute is required to allow the syntax foo=5 in the expression that wouldn't otherwise be allowed.
NOTE:
Tim Wright has pointed out an issue with this approach:
The issue I see is that the same specification might be run from two
different specifications (or run twice from a single specification)
with different parameters as well as from jUnit with no parameters. As
we only create one HTML file, the behaviour might not be what the user
expects. It also means that using concordion:run will create a
different specification from running the spec directly as a jUnit test
- which is something we've tried hard to avoid.
The current behaviour (with the concordion run cache) is that the
first one to be called will create the HTML file - and the second one
will return a run results from the cache thus ignoring the parameter.
This may mean that we deprecate concordion:params and remove it in 2.0.
A custom plugin we wrote for an older version of Jenkins uses an EnvironmentContributingAction to provide environment variables to the execution so they could be used in future build steps and passed as parameters to downstream jobs.
While attempting to convert our build to workflow, I'm having trouble accessing these variables:
node {
// this step queries an API and puts the results in
// environment variables called FE1|BE1_INTERNAL_ADDRESS
step([$class: 'SomeClass', parameter: foo])
// this ends up echoing 'null and null'
echo "${env.FE1_INTERNAL_ADDRESS} and ${env.BE1_INTERNAL_ADDRESS}"
}
Is there a way to access the environment variable that was injected? Do I have to convert this functionality to a build wrapper instead?
EnvironmentContributingAction is currently limited to AbstractBuilds, which WorkflowRuns are not, so pending JENKINS-29537 which I just filed, your plugin would need to be modified somehow. Options include:
Have the builder add a plain Action instead, then register an EnvironmentContributor whose buildEnvironmentFor(Run, …) checks for its presence using Run.getAction(Class).
Switch to a SimpleBuildWrapper which defines the environment variables within a scope, then invoke it from Workflow using the wrap step.
Depend on workflow-step-api and define a custom Workflow Step with comparable functionality but directly returning a List<String> or whatever makes sense in your context. (code sample)
Since PR-2975 is merged, you are able to use new interface:
void buildEnvVars(#Nonnull Run<?, ?> run, #Nonnull EnvVars env, #CheckForNull Node node)
It will be used by old type of builds as well.
I have the following requirement.
from Ant xmlproperty task. What happens when there is more than one tag with the same name?
it's clear how to repeat for each file.
My requirement is to iterate for each file and I would like to get the value of 'machine' element for corresponding file
eg:
<echo>${PREFIX.main.tagList.tag.file[file1]}</echo> // should return machine1
<echo>${PREFIX.main.tagList.tag.file[file2]}</echo> // should return machine2
An example would help, but I think I discovered this limitation in the xmlproperty task before. For performing complex processing of external files I would use an embedded groovy task, which just loves XML :-)
You haven't specified a sample input, so here's a similar example:
Parse HTML using with an Ant Script