test: [M3-7091] - Add integration tests for Cloud Manager invoices, DC-specific pricing

[jdamore-linode]

Description 📝

Refactors existing tests and adds new tests to improve Cloud Manager's test coverage for invoices and to account for DC-specific pricing changes.

Major Changes 🔄

• Moves existing billing- and payment-related tests from the "accounts" directory to a new "billing" directory
• Refactors existing billing activity section tests to add coverage for:
  • Payments listed in the "Billing & Payment History" table
  • Filtering transaction types using the transaction type drop-down
  • Filtering by payment/invoice date using the date range drop-down
  • Configuring and using pagination controls for accounts with long invoice history
  • Clicking an invoice label navigates to the corresponding invoice details page
• Refactors the billing activity timezone tests to improve performance by removing extra calls tocy.visitWithLogin()
• Adds new billing invoice integration tests which cover the following:
  • Confirms that invoice items are listed on the invoice details page with expected info
  • Confirms that invoice total is shown in header and in invoice summary
  • Confirms that total tax, tax summary breakdown, subtotal, and grand total are shown in invoice summary
  • Confirms that the "Regions" column is not present when DC-specific pricing is disabled, and is present when DC-specific pricing is enabled
  • Confirms that clicking the "Back to Billing" button redirects back to /account/billing
  • Confirms that pagination controls can be used for invoices with many items
• Adds some data-qa-* attributes in src to facilitate tests
• Adds various utilities, UI helpers, and mocks to facilitate tests

How to test 🧪

yarn && yarn build && yarn start:manager:ci, and then:

yarn cy:run -s "cypress/e2e/core/billing/billing-invoices.spec.ts,cypress/e2e/core/billing/smoke-billing-activity.spec.ts"

[bnussman-akamai]

Awesome! 🤯🎉 Thanks joe!

[cpathipa]

Nice work @jdamore-linode!

[mjac0bs]

🎉 Thanks for this added coverage! All passing and overall looking clear and good.

I just left a question related to mock invoice items and a small ask to update the TODOs so that they're easier to find later. If you think we need a separate ticket beside M3-7073 for this, let me know and I will make one.

[mjac0bs]

Thanks for the updates! Confirmed tests are still all passing locally; this looks ready to 🚢 .

[abailly-akamai]

Ran locally, all looking good 👍

[abailly-akamai]

I feel like this belongs to an integration test as it's not relevant to the billing table alone

[jdamore-linode]

@abailly-akamai Just to clarify, when I talk about integration tests, I'm usually referring to UI tests which use mock API data to confirm that a Cloud Manager feature/flow works with the system (in our case, the backend) as a whole without actually depending on it. Similarly, when I talk about end-to-end tests I'm still talking about UI tests, but which use real API requests to validate features and flows across the whole stack.

I think you're talking more about component testing (and I think an argument can be made that a component test is a form of an integration test, which is why I hate software testing terminology 😅), but we don't really have the capability to do component testing beyond what we're already doing with Jest. Cypress added component testing functionality relatively recently, which would probably be a great middle ground between our Jest tests and our Cypress UI tests, but they would exist as a separate suite of tests (and would therefore require pipeline changes, etc., to accommodate). To your point, the pagination components would be great candidates for component testing since they're used all over the place and their existing test coverage is somewhat lacking (1, 2).

However, the Pagination components still leave a lot up to the developer when it comes time for implementation: handling the page changing, or the pagination size changing, and fetching/transforming/providing the paginated data is all outside the scope of the <PaginationFooter /> component, for example (the usePagination() hook helps mitigate the first two points, but it's only a convention; there's no guarantee that every paginated view uses that hook, and indeed, the Billing Activity panel's pagination logic does not). All of this is to say that a test which confirms that the Pagination component(s) work doesn't necessarily confirm that all of our paginated tables across the app work, too.

I don't think we should go testing pagination for every single paginated view in Cloud, but given the importance of the billing sections, and the fact that we do some funky stuff with combining API data from two endpoints on the Billing Activity Panel and paginating it together, I think it's probably good to have these specific implementations covered.

[abailly-akamai]

Thanks for clarifying, i understand why it's relevant here. Yeah in my head a component test is a form of integration test, cause you'd want to test it so that given a certain set of data it will always return the same result (they're both UI tests), but i understand the separation of concern here. Also, everything is a component I guess...

We could also do component testing at the Storybook level if we wanted, but prob better to leave this for the next component library we adopt unless it's really crucial

[jdamore-linode]

I have a really old spike ticket to explore Cypress component testing, and I think there may be a similar spike to look into Storybook's component testing. They were never a high priority and eventually slipped through the cracks, but in light of our new quality/reliability push, it might be worth prioritizing this. (Might be a good opportunity to look into visual regression testing too)