Merpay Frontend - Building a Testing Culture

By @wilsonplau

Transcript

1. 1 Merpay Frontend Building a Testing Culture @wilsonplau
2. 2 Background 2019.2–3 iD Payments/ QR Code Payments Available at 2.06 million iD and Merpay merchants nationwide, including convenience stores, restaurants, drug stores, and fast food *As of March 31, 2021 (merchants with both iD/QR counted once only) 2020.7 Merpay Smart Payments Allows users to defer payment for items based on past usage of Mercari and Merpay Online Payments Enables use of Merpay for not only offline purchases, but online as well 2020.9 Send/receive Enables users to send their Merpay balance/points to family and friends No-contact service 2019.4–5 Growing Wallet Enables users to utilize their Merpay balance on the peer-to-peer investment service Funds *Second investment fund went live in January 2021 2020.11 2021.3 Shared d Payment/ Merpay QR code Enables use of single QR code for both d Payment and Merpay Virtual card Enables users to easily issue a card number which can be used to pay using Merpay balance at many online stores Identity verification using Japan’s Individual Number Card (JPKI) Launched support for identity verification using Japan’s public Individual Number Card identification service (JPKI) Merpay Smart Payments (fixed-amount) Allows for “fixed-amount payments,” whereby users pay in installments from the following month onwards Mercari Donation Enables donation of Merpay balance, charged from Mercari sales balance or bank account, etc., to local governments and other organizations of the user’s choice
3. 3 Background How do we maintain our development velocity? • Reduce manual QA time requirements • Increase confidence when doing maintenance tasks and refactoring • Onboarding new team members / learning new products ◦ Using tests as a reference, new members can quickly understand specs • Increase velocity in new feature development ◦ Fully mocked backend APIs lets us develop at the same time as backend ◦ Implementation-agnostic tests allows us to write tests and product code simultaneously • Reduce bugs and issues in general
4. 4 Culture > Tactics Culture is more important than tooling & tactics • Tactics change, culture persists. • Like all frontend, I have no doubt we’ll be using different tools in the future. We want to build a team that is excited to evolve our testing as well. • So, how do you build and maintain a culture of testing? ◦ Reinforce moments of magic ◦ Maintain tests as spec ◦ Make tests easy to read and write ◦ Measure, measure, measure ◦ Everyone is responsible for tests
5. 5 1. Reinforce moments of Magic We gain an appreciation of testing with every big refactoring we undertake, every bug we catch, every complex release we do. 🔥 Build a culture that shares these moments of magic in retrospectives, in PRs, et.
6. 6 2. Maintaining tests as spec Frontend teams have a responsibility to maintain tests to keep up-to-date with the full specifications of the product. When specs change, tests change. Less ambiguity around what tests to write make it easier for everyone.
7. 7 3. Make tests easy to read and write Tests that are easy to read and write will be maintained better, and used more than those that are not. • When tests are easy to read: they can be read as a specification document • When tests are easy to write: we write more of them • To achieve this: ◦ Create and maintain utilities / abstractions to reduce repetition, make test code clear and easy to understand ◦ Maintain a consistent test structure so the location of tests is easy to figure out, just like all other code structure.
8. 8 3. Make tests easy to read and write describe(“Form”, () => { it(“should render the form”, () => { cy.mock(UserAPI.getUser, { email: ‘test@email.com’ }); cy.getByTestId(“testForm”) .assertTextInput(“Email”, “default@email.com”, { placeholder: “Email” }) .assertSelect(“True/False”, null, { values: [“True”, “False”] }) .assertButton(“Confirm”); }); }); Tests that are easy to read and write will be maintained better, and used more than those that are not.
9. 9 3. Make tests easy to read and write describe(“/dashboard”, () => { describe(“rendering:”, () => { it(“should render the form correctly”, () => { ... }); }); describe(“validation:”, () => { it(“should validate the name input correctly”, () => { ... }); it(“should not be able submit the form when errors exist”, () => { ... }); }); describe(“actions:”, () = { it(“should be able to submit the form successfully”, () => { ... }); }); }); Tests that are easy to read and write will be maintained better, and used more than those that are not.
10. 10 4. Measure, measure, measure • Everyone likes seeing green. ◦ One of the earliest things we did was to setup these measurement tools (Looker) in order to increase visibility of metrics • As imperfect as code coverage metrics are, I think they’re important for providing a constant reminder of the importance of testing. ◦ The metrics are gameable, but make tests easy enough to write (3), and there will be no reason not to just write them. Having visible metrics reinforces a culture of testing, and gives us an idea of where to focus next
11. 11 4. Measure, measure, measure
12. 12 4. Measure, measure, measure
13. 13 4. Measure, measure, measure
14. 14 5. Everyone is responsible for tests • We have an amazing QA team inside Merpay that we can rely on 100%. • However, relying on QA too much is a negative mentality ◦ We should test our apps so thoroughly that, even if we did not have a QA team, we would have enough confidence to release and maintain the app. • QA is there to be a second perspective and second check ◦ QA develops test cases differently - from a black box perspective unlike the frontend team. We also should not know what/how QA is testing. • Duplication of tests is 100% fine and even encouraged Testing is not only for QA. We all have a collective responsibility to maintain tests.
15. 15 Thank you!