-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(simple-book-free-opportunities): Create with-erroneous-payment-property-test #127
feat(simple-book-free-opportunities): Create with-erroneous-payment-property-test #127
Conversation
…roperty-test Additionally: - Update breq so that it can use different templates if needed (e.g. to ensure that a B request includes a `payment` property for free opportunities) - Update without-payment-property-test so that it is always explicitly withholding the `payment` property - Partially type chakram, which does not, unfortunately have any community TS defines
@@ -76,16 +76,11 @@ function (configuration, orderItemCriteria, featureIsImplemented, logger, state, | |||
|
|||
return chakram.wait(); | |||
}); | |||
|
|||
afterAll(async function () { | |||
await state.deleteOrder(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Based on our earlier conversation, I've removed this from the default advice for new tests
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lukehesluke think I mentioned before, but I wonder if we should in fact make this configurable? As it might be that systems want to minimise the number of new orders created, especially in Random mode?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That makes sense, @nickevansuk . So I'll leave this for now (as we'd probably want this configuration option to be exercised in the feature-helper rather than in the tests' afterAll blocks?) and then create an issue for setting this up. Sound good?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds great!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Issue: #142
// This must also be TestOpportunityBookableFree as the payment property is only disallowed if ALL items are free. | ||
controlOpportunityCriteria: 'TestOpportunityBookableFree', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just want to confirm that this makes sense. My theory so far is that the "control" is so that the "multiple order items" test has some normal opportunities as well as the specialised opportunities relevant to the test.
In this case, I've set the control to free because the use case can only be tested if the entire basket is free (payment
is only forbidden if all opps are free)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep that's right, and makes sense
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Love the templating approach!
…th-erroneous-payment-property
Additionally:
payment
property for free opportunities)payment
property