How to validate 204 response code in restassured using cucumber ,need to know how to write steps for that in step definition?
Related
I have a Java based test suite running Bazel 4.2.2, and my goal is to collect code coverage regardless of test flakiness. I tried to add these options:
bazel coverage ... --runs_per_test=3 --cache_test_results=no ...
but it looks like if 1/3 of those fail, then the test is failed and coverage data is not collected for failing tests.
Does Bazel have any flags to take the first passing result, and retry only on failures?
The full command I've tried is
bazel coverage --jobs=6 --runs_per_test=3 --cache_test_results=no --combined_report=lcov --coverage_report_generator="#bazel_tools//tools/test/CoverageOutputGenerator/java/com/google/devtools/coverageoutputgenerator:Main" -- //$TARGET/... 2>&1
Thanks!
Answer to my question (can't accept it yet): there's an option in the documentation I found
https://docs.bazel.build/versions/0.25.0/command-line-reference.html
--flaky_test_attempts=<a positive integer, the string "default", or test_regex#attempts. This flag may be passed more than once> multiple uses are accumulated
Each test will be retried up to the specified number of times in case of any test failure. Tests that required more than one attempt to pass would be marked as 'FLAKY' in the test summary. If this option is set, it should specify an int N or the string 'default'. If it's an int, then all tests will be run up to N times. If it is not specified or its value is ' default', then only a single test attempt will be made for regular tests and three for tests marked explicitly as flaky by their rule (flaky=1 attribute).
Another option is using the flaky attribute on your test rules for the problematic tests. That will run them up to 3 times even with normal bazel test, without needing any flags.
Let me start by stating I am very wet behind the ear with gherkins and cucumber.
I've put together a PoC for my company of an integration a Jenkins projects that will build and execute tests when there is a check in a Git repository. When the tests have completed Jenkins will then update the test managed in Xray for Jira.
The tests are cucumber written using gherkins. I have in vain attempted to cause a single test to produce a failure just to be able to add that to the demo I am going to be giving to upper management.
Here is the contents of my file HelloWorld.feature:
Feature: First Hello World
#firsth #hello #XT-93
Scenario Outline: First Hello World
Given I have "<task>" task
And Step from "<scenario>" in "<file>" feature file
When I attempt to solve it
Then I surely succeed
Examples:
| task | scenario | file |
| first | First Hello | First Feature |
Currently all the tests I have pass. I have attempted to modify that test so that it would fail but thus far have only been able to get it to show in Xray as EXECUTING or TO DO.
I have searched to see if it was possible to create a test that would always result in a test failure but have not been able to find anything.
I know do not know gherkins, I'm only using what was given to me to work with, so please forgive my question.
Thank you for any guidance anyone might be able to provide.
Cucumber assumes a step passes if no exception is thrown. Causing a test to fail is easy. Just throw an exception in the step definition.
Most unit testing frameworks give you an explicit way to fail a test. You haven't mentioned the tech stack in use, but MS Test for .NET gives you Assert.Fail("reason for failure goes here.");
Or simply throw an explicit exception: throw new Exception("fail test on purpose");
As long as the step throws an exception the entire scenario should fail.
I am trying to configure Jenkins Build Parameter "users" ,to be passed as input to JMETER (v5.1) --> No.Of Threads using the function:${__javaScript(Math.round(${XX}))}
While executing test i am getting following error
error : caused by jdk.nashorn.internal.runtime.ParserException::1:12 Expected but found { Math.round(${__jexl())}
Use a variable to store Math.round(${. Test it with println. Then Invoke ${__javaScript(myVariable)}. Nested ${} is a bad idea, groovy interprets them.
as M Navneet Krishna said, your question is a bit succinct for us to provide better answer. But I gave you a method that should help you debug your stuff
I am planning to use RESTAssured for API Testing in our project.
I am wondering if any mechanism is available to determine the test coverage.
I did google search but didn't find any answer.
First of all, what kind of coverage?
-Requirement
-Code
-Endpoint
-Method
-Bug
-Environment
-etc.
I guess endpoint and/or requirement coverage you want to earn: Create a coverage matrix where you mark the covered endpoint and its method (y axis) with test case (x axis). The input endpoints can be granted in prior since you should know them. The rest can be collectet in runtime with a collector util.
I personaly used a custom annotation for tests where I marked the used endpoint(s) whilst the test result was provided by testNg ITestListener. At the end with a custom reporter I made my own coverage result as a heatmap.
I want to make the build fail by analyzing the results of the console log, for a mac project I am building. It builds each module and gives the results like this:
###################################
XX XXX XXX
##########################
It then returns BUILD FAILED
I want to show that the build failed at the end of the console output, and at the same time I want to know which module failed. It should be sent by email since I am already using the email-ext plugin.
I am unsure of what needs to be done; I am aware of text-finder, log parser and setting the run condition - but do not know what steps to follow.
You will need to use the text-finder plugin and the email-ext plugin together in order to accomplish both your objectives.
First set up the text-finder plugin and provide an appropriate regex. Something like: .*(?i)failed.*|.*(?i)error.* would find the words "failed" or "error" in a case insensitive manner. You will need to specify a path to your log files and probably want to check the "Also search console output" check box.
This will cause any build which outputs "failed" or "error" to fail in Jenkins.
Your requirement to email the module which failed is a little more complex, but possible with the email-ext plugin. This plugin allows you to specify a regex which is used to gather email content using a special token which accepts arguments. The full argument list and token name is: ${BUILD_LOG_REGEX, regex, linesBefore, linesAfter, maxMatches, showTruncatedLines, substText, escapeHtml, matchedLineHtmlStyle}
Most of these arguments are optional, something like this should do the trick for you: ${BUILD_LOG_REGEX, regex=".*(?i)failed.*|.*(?i)error.*", linesBefore=10, linesAfter=10}. Put this in the "Default Content" section of the email-ext configuration. You can specify multiple tokens as well, see this answer for instructions to get the full list: Jenkins Email-ext plugin - tokens
You can of course edit the LinesBefore and LinesAfter parameters to suit your needs.