...
User Role | Description |
---|---|
User | User will be placing successful orders on Whitelabel |
Developer user | User responsible for: Build and run the local environment and set the mocks |
Analytics user | User responsible for checking the events on mParticle/Amplitude. |
Whitelabel
General configs and pre-
...
conditions:
Feature flags Intl Platform (backend):
disable-paycomet-pre-auth: this FF need needs to be enabled with these configs:
...
When the const ccc = ''; here you can set the backend error that you want to simulate. E.g. 2.001, 2.100.001 and etc.
2- 1 to manipulate the content of the Lokalise existing on the local environment Setup and run locally the Intl-whitelabel-frontend
Edit the file src/utils/errors/index.ts
replace the existing code from line 238 by the 261 by the code below:
Code Block |
---|
export const getRbiErrorTranslation = ({
errorCode,
errorTranslation,
defaultTranslationId,
formatMessage,
}: IRbiErrorTranslation) => {
const parsedErrorCodes = errorCode ? extractRbiErrorCodes(errorCode) : [];
const foundTranslation = parsedErrorCodes.find(code => {
const key = errorTranslation ? `error.${code}.${errorTranslation}` : `error.${code}`;
return formatMessageMock({ id: key as TLocalizationKey }) !== key;
});
const getFormattedMessage = (translation: string) =>
formatMessageMock({
id: errorTranslation
? (`error.${translation}.${errorTranslation}` as TLocalizationKey)
: (`error.${translation}` as TLocalizationKey),
});
return foundTranslation
? getFormattedMessage(foundTranslation)
: formatMessageMock({ id: defaultTranslationId as TLocalizationKey });
}; |
Go to line 21 and add the code below:
Code Block |
---|
export const formatMessageMock = ({ id }: { id: string }) => {
const keys: Record<string, string> = {
'error.payment.title': 'Uh oh!',
'error.payment.default': 'Something went wrong, please try again.',
'error.payment.cta': 'Go back',
'error.payment.2.001.title': 'Card type invalid',
'error.payment.2.001.cta': 'Pay another way',
'error.payment.2.001': 'Your card is not enabled to allow this payment at the moment. Please, contact your bank or try another payment method.',
};
return keys[id] ?? id;
}; |
Now on this same part, add new variables and remove them according to the pre-conditions for each test case.
Build and run the front end and access the local host.
In order to simulate the error, you can use the specific credit card available by Paycomet on this document: https://docs.paycomet.com/en/recursos/testcards in the section Test Cards to force an error.
You can use any code available on this document: https://docs.paycomet.com/en/recursos/codigos-de-error on the CVV field, it will not make a difference, because you already created a mock on backend.
Test case scenario part 1:
Scenario 1: [Split logic][Mapped errors][Title message] Validate the split logic different levels of error messages on the title message when all the errors are mapped on the Lokalise file
Scenario 2: [Split logic][Non-mapped errors][Title message] Validate the split logic different levels of error messages on the title message when some errors are NOT mapped on the Lokalise file
Scenario 3: [Split logic][Mapped errors][Message description] Validate the split logic different levels of error messages on the message description when all the errors are mapped on the Lokalise file
Scenario 4: [Split logic][Non-mapped errors][Message description] Validate the split logic different levels of error messages on the message description when some errors are NOT mapped on the Lokalise file
Scenario 5: [Split logic][Mapped errors][Modal buttoncta] Validate the split logic different levels of error messages on the modal button cta when all the errors are mapped on the Lokalise file
Scenario 6: [Split logic][Non-mapped errors][Modal buttoncta] Validate the split logic different levels of error messages on the modal button cta when some errors are NOT mapped on the Lokalise
Test Part 2:
We will be able to use Paycomet’s instruction The objective of test part 2 is really validate the codes already implemented on the backend and check if the messages on the frontend are correct according to the map.
You can validate using the test environments and just in case you want to local it is necessary to remove any mocks applied.
Use Paycomet’s instructions to simulate some of the mapped errors. In this case, we need to use the CVV field and enter the code informed by Paycomet. The codes are availabe on this document.If there is no code available to test, we will need to use a mock in order to simulate the errorsavailable in this document.
Scenario 7: [Mapped errors] Validate title error, modal description and modal button cta according to the mapped errors on the Lokalise
Scenario 9: [Regression testing] Validate if the button cta on the modal redirects the user to the cart page and the order is not placed
Analytics
Test Part 3:
Scenario 1012: [Analytics] Validate if the attributes were added on to the existing modal appearance event
Scenario 1113: [Analytics] Validate if the attributes were an attribute was removed on the existing modal appearance and if an attribute is being sent as "null”
Scenario 15: [Analytics] Validate analytics when the user set a different language from the default
Scenario 1216: [Analytics] Validate if the attributes were removed on the existing modal appearance eventthe modal using a different language according to the translation available on the Lokalise