Forum Discussion
Ah, the assertions are hard-coded into each test step?
You could added the expected results to your datasouce; take out the hard-coded assertions from the test step and create a groovy script to perform the assertion on every iteration.
E.g. Modify the datasource to include the params for each test and the expected result.
Customer Id | Customer Name | Credit Limit | Sale | Expected Credit Check Result |
1 | John | 1000 | 800 | PASS |
2 | Paul | 900 | 1000 | FAIL |
3 | George | 800 | 200 | PASS |
4 | Ringo | 700 | 900 | FAIL |
Update the Datasource to reference the new columns....
Remove the hard-coded assertions from Test Steps 001, 002, 003 etc. No screenshot here.
Add a groovy script step.....
Open the Assertion Groovy Step and create you check. Here's a pseudo-like example.
// Let's get the params and expected result for our test.
def customerId = context.expand( '${Customer Data Source#customerId}' )
def customerName = context.expand( '${Customer Data Source#customerName}' )
def creditLimit = context.expand( '${Customer Data Source#Credit Limit}' )
def sale = context.expand( '${Customer Data Source#Sale}' )
def expectedCreditCheckResult = context.expand( '${Customer Data Source#Expected Credit Check Result}' )
log.info("Testing Customer ${customerId} ${customerName}. Credit Limit ${creditLimit}. Sale ${sale}. Expected Result ${expectedCreditCheckResult}.");
// Get the result of the credit check from the test step.
// Big assumption here, so this is just an example, but assuming the response from the SOAP Request contains the result.
// Use Get Data to find the path to the variable of interest...
def actualResult = context.expand( '${SOAP Test Request#CreditCheckResult}' );
// Assert!
assert (expectedCreditCheckResult == actualResult);
This assertion will use the data and expected result in current row. No need for a test step per row because of assertions. I think this achieves what you're asking for.
Going futher...
Worth noting, that if the assertion fails, the test stops. You might only be 3 rows in out of a thousand and it's stopped.
I personally don't like this, so I go further.... Instead of the assertion, I check the result and use a datasink step to report this test row. E.g.
Then configure the datasink... Note how we pull the values from the datasource and the step that performs our check.
Lastly, update the Assertion step and make it return the result instead of the assertion.....
// Let's get the params and expected result for our test.
def customerId = context.expand( '${Customer Data Source#customerId}' )
def customerName = context.expand( '${Customer Data Source#customerName}' )
def creditLimit = context.expand( '${Customer Data Source#Credit Limit}' )
def sale = context.expand( '${Customer Data Source#Sale}' )
def expectedCreditCheckResult = context.expand( '${Customer Data Source#Expected Credit Check Result}' )
log.info("Testing Customer ${customerId} ${customerName}. Credit Limit ${creditLimit}. Sale ${sale}. Expected Result ${expectedCreditCheckResult}.");
// Get the result of the credit check from the test step.
// Big assumption here, so this is just an example, but assuming the response from the SOAP Request contains the result.
// Use Get Data to find the path to the variable of interest...
def actualResult = context.expand( '${SOAP Test Request#CreditCheckResult}' );
// Assert!
//assert (expectedCreditCheckResult == actualResult);
// Let's not assert. Just return the result.
if (expectedCreditCheckResult == actualResult) {
return "PASS";
} else {
return "FAIL";
}
So, for each row in the datasource, we can call our service. We then run a check (or assertion) in the following step. Finally, we can report out the result. The result file will be the same as the datasource, but with the result of the check tagged on the end of each row.
This is actually my typical approach. I can then import the text file into Excel and format it nicely.
thanks for all the detail here. I'm going to work through some examples.
- richie4 years agoCommunity HeroHey davecoleman,
I never bothered responding to this as ChrisAdams was doing a cracking job and i couldnt have even come close to adding anything, but i just wanted to mention something in regards to your hardcoded assertions.
Obviously i dont know what youre asserting against in your responses, however if the testdata tests are changing everyday im guessing the expected results are changing everyday. With this in mind, i just wanted to highlight you can parameterise your assertions within the GUI, rather than hardcode them. I do this as much as possible (along with some other "tricks" (i.e. setup scripts, project/testsuite/testcase level properties, setup testsuites, reusable code, parameterisation) when creating a ReadyAPI project so i can lift and shift my ReadyAPI project to point at completely different environments with completely different data without having to change anything in project). If you know the assertion values for each testcase, you could include these in your Excel Datasource as an additional field for each test case. You could then parameterise your assertion to point to these values, removing the need to change hardcoded values.
Ok, that was all i wanted to mention,
Cheers,
Rich
Related Content
- 4 years ago
- 4 years ago
Recent Discussions
- 5 days ago
- 8 days ago
- 19 days ago