Test Mode In Process Development - rettersoft/rbs-docs GitHub Wiki
Test processes must set "test" flag as boolean "TRUE" to enable test mode. Thus, you will be able to use custom tokens when you call other services. As best practice, test processes should have been designed to run in "express" mode.
Promotions Story
Promotions Story is for testing new or existing group of promotions with custom user tokens. Accordingly, it has multiple processes to create and apply promotions in various scenarios.
Filling Shopping Cart & Returning Cart Summary By User
This part of the story has been designed reusable. In a different process, you can call this process directly and evaluate the results to test various promotions.
interface CartItem {
merchantId: string // "default"
variantGroupId: string
itemId: string
qty: number
}
interface Payload {
userId?: string
roles?: string[]
phoneNumber: string
items: CartItem[]
}
interface Result {
profile: {key: string, any}
token: string
summary: CartSummaryResponse
}
[DEFAULT_PROFILE |
state: {
"defaultUserId.$": "$$.ULID",
"defaultRoles": \["enduser"\]
}
]
[PROFILE |
state: {
"profile": {
"userId.$": "$$.OR($.payload.userId, $.defaultUserId)",
"roles.$": "$$.OR($.payload.roles, $.defaultRoles)",
"phoneNumber.$": "$.payload.phoneNumber"
}
} |
onHasToken: { "payload.token": { "EX": true } }
]
[TOKEN |
state: {
"newToken": {
"customToken.$": "$.payload.token"
}
}
]
[GENERATE_TOKEN |
action: rbs.core.request.GENERATE_CUSTOM_TOKEN |
parameters: {
"userId.$": "$.profile.userId",
"roleNames.$": "$.profile.roles",
"claims": {
"msisdn.$": "$.profile.phoneNumber"
}
} |
resultPath: newToken |
outputPath: $.0.response |
errorPath: $.0.errors.0 |
onSuccess: { "newToken.customToken": { "EX": true } }
]
[ADD_ITEMS_TO_CART |
action: rbs.cart.request.SET_ITEMS |
parameters: {
"items.$": "$.payload.items"
} |
resultPath: cart |
outputPath: $.0 |
auth: { "token.$": "$.newToken.customToken" } |
onSuccess: { "cart.status": { "EQ": 200 } } |
In future, we should start the process
instead of calling the action directly!
]
[CART_SUMMARY |
action: rbs.cart.request.SUMMARY |
inputPath: $.payload.cartSummary |
resultPath: summary |
outputPath: $.0 |
auth: { "token.$": "$.newToken.customToken" } |
onEmptyCart: { "payload.keepCart": { "NE": true } } |
onSuccess: { "summary.status": { "EQ": 200 } }
]
[EMPTY_CART |
action: rbs.cart.request.CLEAR |
parameters: {} |
auth: { "token.$": "$.newToken.customToken" } |
onSuccess: { "summary.status": { "EQ": 200 } }
]
[SUCCESS |
parameters: {
"profile.$": "$.profile",
"token.$": "$.newToken.customToken",
"summary.$": "$.summary.response"
}
]
[CANNOT_CREATE_TOKEN |
error: Generating a new token has been failed!
]
[CANNOT_ADD_TO_CART |
error: Adding product(s) to your shopping cart has been failed!
]
[CART_SUMMARY_FAILED |
error: Cart summary has been failed!
]
[FAILED |
error: Test has been failed! |
parameters: {
"profile.$": "$.profile",
"token.$": "$.newToken.customToken",
"summary.$": "$.summary.response"
}
]
[DEFAULT_PROFILE] -> [PROFILE]
[PROFILE] -> (onHasToken) [TOKEN]
[PROFILE] -> [GENERATE_TOKEN]
[TOKEN] -> [ADD_ITEMS_TO_CART]
[GENERATE_TOKEN] -> (onSuccess) [ADD_ITEMS_TO_CART]
[GENERATE_TOKEN] -> [CANNOT_CREATE_TOKEN]
[CANNOT_CREATE_TOKEN] -> [FAILED]
[ADD_ITEMS_TO_CART] -> (onSuccess) [CART_SUMMARY]
[ADD_ITEMS_TO_CART] -> [CANNOT_ADD_TO_CART]
[CANNOT_ADD_TO_CART] -> [FAILED]
[CART_SUMMARY] -> (onEmptyCart) [EMPTY_CART]
[EMPTY_CART] -> (onSuccess) [SUCCESS]
[EMPTY_CART] -> [CART_SUMMARY_FAILED]
[CART_SUMMARY] -> (onSuccess) [SUCCESS]
[CART_SUMMARY] -> [CART_SUMMARY_FAILED]
[CART_SUMMARY_FAILED] -> [FAILED]
Evaluating Cart Summary
Once we started the process above in express mode, we will get the results as response and we will be able to run assertions against them. If cart summary operation has been failed before assertion level, a proper error must show up in the first place.
[EXECUTE |
process: TEST_CART_SUMMARY |
invocationType: EXPRESS |
resultPath: results |
errorPath: $.0.response.error
]
[EVALUATE |
Put assertions here!
]
[EXECUTE] -> [EVALUATE]
Creating Scenario-based Promotions
In most cases, we have to test promotions together to see their isolation statuses in various shopping carts. By modifying the process below, you can create various promotions according to your needs and see their effects on your shopping carts.
interface Payload {
promotions: PromotionInput[]
}
[CREATE_PROMOTIONS |
action: rbs.promotion.request.CREATE |
each: $.payload.promotions |
resultPath: promotions
]
[CHECK_PROMOTIONS |
st: {
"count": "{{ promotions.length }}",
"ids": "{{ promotions.map(p => p.id) }}"
}
resultPath: createdPromotions |
onSuccess: { "createdPromotions.count": { "EQ": 2 } } |
This should return detailed metadata about created promotions.
]
[EXECUTE |
process: TEST_CART_SUMMARY |
invocationType: EXPRESS |
resultPath: results |
errorPath: $.0.response.error
]
[DELETE_PROMOTIONS |
action: rbs.promotion.request.DELETE |
each: $.createdPromotions.ids
]
[EVALUATE |
Put assertions here!
]
[CREATE_PROMOTIONS] -> [CHECK_PROMOTIONS]
[CHECK_PROMOTIONS] -> (onSuccess) [EXECUTE]
[EXECUTE] -> [DELETE_PROMOTIONS]
[DELETE_PROMOTIONS] -> [EVALUATE]
If your scenario requires existing orders, you can create fake usages by calling promotion service like below.
interface OrderInput {
orderId: string
createdAt: number
totalPriceWithTax: { priceAfterInterest: number }
couponCode?: string
appliedPromotions?: Array<{ promotionId: string }>
profile: { uid: string }
}
[SAVE_PROMOTION_USAGE |
action: rbs.promotion.event.SAVE_USAGE |
parameters: {
"order.$": "$.orderInput"
}
]
Testing Other Processes
PM has methods to start processes as well as calling RBS actions. Thus, you can start processes with or without payload and track them just like SDK implementations do on client-side.
To be able to test / debug an existing process, first you need to start the process via rbs.process.request.START or rbs.process.request.START_EXPRESS. After that, you will have a valid execution ID to track its progress.
Main approach is to see which steps the process has been going through and how the state changes through those steps. In express mode, you will have operational data as response but in normal mode, you need to call rbs.process.request.GET_EXECUTION yourself to retrieve that information. When you have current value and steps, you can call rbs.process.request.STEP to see how many times that step has been executed within their input and output values.
Once you collect all the required data, you can easily check their attributes to see if they match certain values.
[START_A_PROCESS]
[GET_EXECUTION_DETAILS_IN_A_LOOP]
[FETCH_STEP_DETAILS_IN_LOOP]
[ASSERT_VALUES_IN_LOOP]
[CHECK_RESULTS]