Cucumber report is missing the doc strings for the responses from a called scenario.
in a given scenario, i am calling multiple scenarios using Call ()
its printing randomly sometimes response from the called scenarios and sometimes not. This is preventing us visualizing the data flow between API in the test report.
Although the karate-log is having the response from that called scenario, its just the cucumber reporting is not printing it. we are using karate 0.9.4, cucumber reporting 4.6.0.
When statement not printing Doc String
I am trying to print it like this.
When Statement with Doc string
Please try with 0.9.6.RC3 - if it still doesn't work it is a bug and please follow this process (we need a way to replicate): https://github.com/intuit/karate/wiki/How-to-Submit-an-Issue
Related
It is well documented how to use an external data file with the Collection Runner in Postman to run multiple iterations. However, what I'd like to do is write tests to compare the response body from a GET request to a JSON/CSV file.
From the research I've done it seems this isn't possible using just Postman. I wonder though if it'd be possible with Newman?
I have no experience with Newman but am curious if this might work. Could you create a Postman collection with an env variable called TestJsonFile and write tests comparing values from that to the response body. Then export said collection and using Newman set the TestJsonFile value to that of a JSON/CSV file (--env-var "TestJsonFile=<path_to_file>") and run the collection with that variable?
This seems plausible to me; maybe I could create a Node project to do it all in one place. I'd just like to ask if anyone has done something similar as it seems like it should be doable.
Any critiques or suggestions would be much appreciated, thank you for reading!
I see the SMT test suite has a 'comment' attribute and also see that atp gem generally supports a test level description. Which should I use to add a line in the rendered SMT flow file? The following does not work when called from here:
func :my_func, comment: "make a comment"
thx
A description is intended to be a meta-documentation of the test, meaning it is potentially long and not rendered to the generated program. Instead it would be used in documentation, that is outlined here - https://origen-sdk.org/origen/guides/program/doc/
This comment attribute directly maps to the comment field in the test program, it does not by default contain the description/documentation though you could probably set it up like that.
When creating a test suite the comment should be picked up. If you are not seeing it in the generated flow, then it probably means that your interface layer is not forwarding that comment option to the test suite creation.
So, either pass the options along when you are calling test_suites.add, or else set it in the test suite object like this: my_test_suite.comment = options[:comment].
In HTML report when a test case fails I don't want the code to appear in the report, only the statements needs to be printed (example of problem). Can anyone help me out here?
I am using Python 3.6, pycharm and generating HTML reports with the help of pytest-html.
Use try and except with in your code and may be include something like below
raise NoSuchElementException("An Error has been registered")
Looking at the documentation under 'Modifying the results table'
https://github.com/pytest-dev/pytest-html
It seems like you should be able to modify the output, which also includes removing. I would suggest trying this approach because the only requirement you have is not displaying the exceptions in the HTML output.
Avoid using try-except constructions in such a way that it suppresses the stacktrace in general, as this will make debugging failed test cases harder to do.
I am facing an issue that I could not understand how to resolve.
I created a test plan that need to connect DB and count the results.
The problem is that Jmeter not perform any validation afterwards, I created a JSSR223 in the JDBC request and just want to print the results and Jmeter not print.
I created another sampler to print the DB results and still Jmeter not printing.
Jmeter just passes this steps,
In the results tree I saw that it connects to DB and failed in the assertion, but why it passes the other steps? and just moving to debug sampler?
I can not print the results, I can not perform any debug since it is just black box.
can someone please advise?
you can see in yellow all the steps that Jmeter not performed and just not exists in the results tree.
enter image description here
Get used to check jmeter.log file, it normally contains information regarding what went wrong, you should be able to figure out the root cause by looking into the log file. If you are not - update your question with jmeter.log file contents (at least essential parts)
My expectation is that your ${Conv_sense} variable is not defined (or cannot be cast to Integer). Double check whether it is defined or not using Debug Sampler and View Results Tree listener combination.
Also don't refer JMeter Variables like ${Conv_sense} in Groovy scripts body, use vars.get('Conv_sense}') instead, otherwise it might conflict with Groovy GStringTemplate resulting in undefined behavior.
I have certain errors which I set in my code, which should add corresponding error messages to the email content of the final build email.
I was thinking of printing something such as ("EMAIL CONTENT ERROR: _______") to the console, reading through it (in a pre-send groovy script?), and adding corresponding error messages for each error found.
I was thinking of using a pre-send groovy script, setting the mimeMessage object(was reading jenkins email-ext documentation). Would this be viable?
Also, I have never used groovy before, so pointers to how to approach this would be extremely helpful(or a link to where i can find an implementation of something with a similar idea of reading console). Any advice would be greatly appreciated. Thanks in advance!
Can you check attaching "Build Log" This would highlight all the process of build process.
This is a very similar concept to the question here. The technique there was to use the log parser plugin to scan the console output for you, and then use groovy to add all the errors into an email.
This is generally a pretty good idea because it also means that you can view the same set of highlighted errors from jenkins itself, rather than just the email.
There are a couple of ways this is different from your setup, the main points are:
Yes, write errors directly to the console in a known format
Set the log parser up with regular expressions that find your error format
Instead of a pre-send script, in this case you would use a groovy template for your email generation
The template reads the error list from the console parser and adds them to your email. Each one is a link that links back to the jenkins console output.