Need To Get The Status of Each Iteration in UFT like Execution Status, Error Message if the that particular iteration is failed and the status of Checkpoint. Whether it is pass or failed. I have checked for one code which i got from another forum but cannot be self explanatory. Can anyone help in getting more clear on the option to get the status of each iteration.
Code:
List<IterationStatus> iterationList = this.Context.ExecutionStatus.IterationStatus;
if (iterationList.Count > 0)
{
this.Context.UserLogger.Info(iterationList[1].CheckpointFailed.ToString());
this.Context.UserLogger.Info(iterationList[1].Succeed.ToString());
}
Related
I have an 'afterEach' hook for each test. This will write some value to json.
The value for 'TestDetails' is available globally in in the test file.
afterEach(function () {
cy.readFile('cypress/dataFiles/data1.json').then(function (t1) {
t1["testDetails"] = testDetailsValue;
cy.writeFile('cypress/dataFiles/data1.json', JSON.stringify(t1));
})
})
The first test is login test and launching the browser and navigating to login page takes more than 10 seconds.
When test is executed, the below error is displayed:
CypressError: `cy.readFile("cypress/dataFiles/data1.json")` timed out after waiting `4000ms`.
Because this error occurred during a `after each` hook we are skipping the remaining tests in the current suite:
Due to this error, unable to write the value in json in after each hook.
Could anyone please help on this?
I think that means that your file doesn't exist. See https://docs.cypress.io/api/commands/readfile#Existence
I am wondering, how can i set callback on fiber error throw.
example:
local fiber = require("fiber")
local status = 0 --in my case stored in db
local function time_consuming()
lua_error
status = 0
end
function external_api_function()
if status == 1 then return "already running" end
status = 1
fiber.create(time_consuming)
return "started"
end
so i want to set status to 0 if time_consuming function falls. Is where any way to catch it?
I think about checking fiber:status on next api visit. Or create a watchdog for fiber, if i want status to be valid. This will work for me, but seems like not the best solution.
There are multiple ways to achieve your goal.
Within your example both fibers (main and time_consuming task) share the same scope - status variable. If you change the value of the status variable in the child fiber, parent fiber will see an update. You can check this using simple snippet:
status = 1
fiber.create(function() status = 0 end)
print(status) -- 0
Now, to catch an exception, use pcall function. It accepts a function as a first argument, calls it and returns status as a first value following one or more function results. There is also xpcall function if you want to analyse the error being caught. It takes error handler as a second argument.
With pcall you may change your time_consuming function like this:
local function time_consuming()
local ok = pcall(function() lua_error end)
if not ok then
status = 0
end
end
and status will successfully updated if lua_error fails.
But usually I consider this as a bad practice. If more fibers share the same state, it may become difficult to maintain due to uncertainty of the order of fiber execution. So for more reliable solution you may want to use interfiber communication primitives aka channels. You will be able to explicitly ask child fiber to tell you its execution status whether it succeed or not using channel:put() and channel:get() function. See documentation for examples.
I've got a jmeter script to test a user journey through a number of forms.
Ideally the email address for each journey would be unique but it's proven difficult to achieve this.
I have a user defined variable for email;
${__V(${__UUID()}${__RandomString(20,abcdefghijklmnopqrstuvwxyz,)}_jmeter#my-co.com)}
Then a BeanShell PreProcessor to create a uniqueID;
int threadNo = ctx.getThreadNum()+1; //to get the thread number in beanshell
int base = 35000;
int uniqueId = threadNo + base;
vars.put("uniqueId", Integer.toString(uniqueId));
Finally, in the POST data I've been defining;
_${__threadNum}.${uniqueId}.${Email}
However if I want to run a long test, the threads loop so I believe the thread number is the same, so the email doesn't change. Or at least the 403 errors seen during longer tests suggest that.
Can the loop count or some other identifier be used on the uniqueId or in the data for the POST perhaps?
You can use the following:
vars.getIteration() - to get current loop number (on Thread Group level)
Counter element or even better ${__counter(FALSE,)} function which will generate incremented number each time being called. See How to Use a Counter in a JMeter Test for details.
However HTTP Status Code 403 stands for "Forbidden"
The server understood the request, but is refusing to fulfill it.
Authorization will not help and the request SHOULD NOT be repeated.
If the request method was not HEAD and the server wishes to make
public why the request has not been fulfilled, it SHOULD describe the
reason for the refusal in the entity. If the server does not wish to
make this information available to the client, the status code 404
(Not Found) can be used instead.
so your problem seems to be connected with something else
def perform
refund_log = {
success: refund_retry.success?,
amount: refund_amount,
action: "refund"
}
if refund_retry.success?
refund_log[:reference] = refund_retry.transaction.id
refund_log[:message] = refund_retry.transaction.status
else
refund_log[:message] = refund_retry.message
refund_log[:params] = {}
refund_retry.errors.each do |error|
refund_log[:params][error.code] = error.message
end
order_transaction.message = refund_log[:params].values.join('|')
raise "delayed RefundJob has failed"
end
end
When I raise "delayed RefundJob has failed" in the else statement, it creates an Airbrake. I want to run the job again if it ends up in the else section.
Is there any way to re-queue the job without raising an exception? And prevent creating an airbrake?
I am using delayed_job version 1.
The cleanest way would be to re-queue, i.e. create a new job and enqueue it, and then exit the method normally.
To elaborate on #Roman's response, you can create a new job, with a retry parameter in it, and enqueue it.
If you maintain the retry parameter (increment it each time you re-enqueue a job), you can track how many retries you made, and thus avoid an endless retry loop.
DelayedJob expects a job to raise an error to requeued, by definition.
From there you can either :
Ignore your execpetion on airbrake side, see https://github.com/airbrake/airbrake#filtering so it still gets queued again without filling your logs
Dive into DelayedJob code where you can see on https://github.com/tobi/delayed_job/blob/master/lib/delayed/job.rb#L65 that a method named reschedule is available and used by run_with_lock ( https://github.com/tobi/delayed_job/blob/master/lib/delayed/job.rb#L99 ). From there you can call reschedule it manually, instead of raising your exception.
About the later solution, I advise adding some mechanism that still fill an airbrake report on the third or later try, you can still detect that something is wrong without the hassle of having your logs filled by the attempts.
I have come across this problem a few times and never been able to resolve it but now I need to solve it once and for all.
I have a procedure which has been throwing runtime errors. This is not a problem as I have an error handler defined at the top of the function and the handler at the bottom something like this:
retryConcat:
On Local Error GoTo concatErr
'Some Code here
Exit Sub
concatErr:
If MsgBox("Could not append the receipt for this transaction to the Receipt viewer logs.", vbExclamation + vbRetryCancel, "Warning - Missing Receipt") = vbRetry Then
err.Clear
GoTo retryConcat
End If
The error handler contains a message box allowing the user to retry if required. Now here is the part which confuses me. The first time an error is thrown it shows the message box and allows the user to retry as expected. The program then jumps to the appropriate line and tries again. However the second time through when the error is thrown it does not jump to the error handler, it jumps out of the procedure and the error handler in the parent catches it instead!
So my question is why does it jump to the parent error handler on subsequent throws. This happens in many places all over my code. In many cases where I can manually check for errors I can stick the code in a while loop to solve it but with runtime errors I am forced to use the error trapping which acts in this rather annoying way.
Any help or advice would be appreciated.
You need ot use Resume retryConcat.
When an error occurs, it jumps into the error handle to concatErr:. You then show the message box, and if the user chooses to retry, the code then jumps to retryConcat. As this you used Goto, it DOES NOT exit the error handler, and so next time the error occurs, it's already in the error handler and has no choice but to raise the error up the chain to the calling procedure.
Using Resume concatRetry allows it to exit the error handler and resume at the required point, meaning next time the error occurs, it can handle is again.
It probably makes it easier to understand, if you imagine the error handler is a state, not a section of code.