Page Comparison

...

This document details how the Detailed payment error messages Allow Payment methods by DOPfeature should be tested

...

Test Scope

...

Out of Scope

...

Whitelabel

General configs and pre-conditions:

Feature flags Intl Platform (backend):

• disable-paycomet-pre-auth: this FF needs to be enabled with these configs:

...

• enable-rbi-error-2: this FF need to be enabled with these configs:

...

Test Part 1:

The test cases in part 1 should be performed in local environment because we are going to need the translations to be manipulated in each variation scenario and we also need to create mocks to simulate the errors coming from the backend. To do this:

1- Setup and run locally the Intl-whitelabel-graphql

• Mock the backend error:

Find this file: intl-whitelabel-graphql/src/functions/graphql/providers/payments.ts

Add the code below:

const ccc = '2';

errorPayload.code = `PAYMENT.${ccc}`;
errorPayload.rbiErrorCode = ccc;

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.

Image Removed

2- Setup and run locally the Intl-whitelabel-frontend

1. Edit the file src/utils/errors/index.ts

• replace the existing code from line 238 by the 261 by the code below:

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:

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;
};

2. Now on this same part, add new variables and remove them according to the pre-conditions for each test case.

3. Build and run the front end and access the local host.

4. 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.

5. 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 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 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 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 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 cta] Validate the different levels of error messages on the modal cta when all the errors are mapped on the Lokalise file

• Scenario 6: [Split logic][Non-mapped errors][Modal cta] Validate the different levels of error messages on the modal cta when some errors are NOT mapped on the Lokalise

Test Part 2:

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 available in this document.

• Scenario 7: [Mapped errors] Validate title error, modal description and modal cta according to the mapped errors on the Lokalise

• Scenario 8: [Regression testing] Validate if the layout and responsive were kept on the existing error modal

• Scenario 9: [Regression testing] Validate if the cta on the modal redirects the user to the cart page and the order is not placed

• Scenario 10: [Mapped errors] Validate the modal using a different language according to the translation available on the Lokalise

• Scenario 11: [Mapped errors] Validate the modal using a different language when the content is not available on the Lokalise

Analytics

Test Part 3:

• Scenario 12: [Analytics] Validate if the attributes were added to the existing modal appearance event

• Scenario 13: [Analytics] Validate if an attribute was removed on the existing modal appearance and if an attribute is being sent as "null”

• Scenario 14: [Analytics] Validate if the new custom event “Error” is being triggered when the modal is displayed

• Scenario 15: [Analytics] Validate analytics when the user set a different language from the default

• Scenario 16: [Analytics] Validate the modal using a different language according to the translation available on the LokaliseDOP

  • Scenario 1: As a user, I should see the new Edit Payment Method form on the Payment method edit page

  • Scenario 2: As a user I should see the elements on the Edit Payment Method form

  • Scenario 3: As a user I should see the default value as null on all the active/inactive payment methods listed

  • Scenario 4: As a user I want to activate a payment method for one restaurant

  • Scenario 5: As a user I want to activate two or more payment methods for one restaurant

  • Scenario 6: As a user I want to inactivate a payment method for one restaurant

  • Scenario 7: As a user I want to inactivate two or more payment methods for one restaurant

  • Scenario 8: As a user I want to activate a payment method and inactivate another one for one restaurant

  • Scenario 9: As a user I want to activate a payment method for a restaurant group

  • Scenario 10: As a user I want to activate a payment method for a large amount of restaurants

  • Scenario 11: As a user I want to activate a payment method and inactivate another one for a large amount of restaurants

• Whitelabel

  • Scenario 12: As a user I do NOT want to see the payment methods that are null for a restaurant on WL

  • Scenario 13: As a user I want to see the payment methods that are activated for a restaurant on WL

  • Scenario 14: As a user I do NOT want to see the payment methods that are inactivated for a restaurant on WL

  • Scenario 15: As a user I do NOT want to see the payment methods that are activated but the feature flags disabled for a restaurant on WL