Skip to content

Test Category Guidelines

Automated Test Types

We typically maintain the following automated tests, and a determination of the appropriate category for each is required.

Unit Test

  • Use for isolated methods or classes without dependencies.
  • Focus on verifying individual logic.

Integration Test

  • Use for APIs or components with mocked DB and dependencies.
  • Focus on testing interactions within a single area and one API.

Regression Test (End-to-end API tests)

  • Use for workflows or critical features or cross functionality impacted by bug fixes.
  • Focus on testing user behaviours and end-to-end workflow.
  • Need assertions based on the feature, including database or Firebase assertions.

Decision Tree for Test Types

Step 1: Are you testing a single method or class in isolation?

  • ✅ Yes → Write a Unit Test.
  • 🚫 No → Proceed to Step 2.

Step 2: Does this test only focus inside this area or only for one API?

  • ✅ Yes → Write an Integration Test.
  • 🚫 No → Proceed to Step 3.

Step 3: Is this a end-to-end workflow or a bug fix that could impact other functionality?

  • ✅ Yes → Proceed to Step 4.
  • 🚫 No → Write an Integration Test.

Step 4: Is this the lowest level I can implement the test code?

  • ✅ Yes → Write a Regression Test.
  • 🚫 No → Write an Integration Test.

Flow Chart

    graph TD  
        A[Are you testing a single method or class in isolation?] -->|Yes| B[Write a Unit Test]  
        A -->|No| C[Does this test only focus inside this area or only for one API with mocked DB and dependencies?]  
        C -->|Yes| D[Write an Integration Test]  
        C -->|No| E[Is this an end-to-end workflow or a bug fix that could impact other functionality?]  
        E -->|Yes| F[Is this the lowest level I can implement the test code?]  
        E -->|No| D[Write an Integration Test]  
        F -->|Yes| G[Write a Regression Test]  
        F -->|No| D[Write an Integration Test]

Examples

Transaction ATM fee

ATM transaction fees can't easily be tested in a real-world scenario during development. Here's why it fits under integration testing:
* Complex interactions: It involves multiple components like the ATM interface, the banking backend, fee calculation logic, and possibly external payment gateways. Integration tests ensure all these systems work together correctly.

  • Simulating real-world behavior: Integration tests allow developers to replicate the scenario of deducting fees from an account without actually using real money or real ATMs, making it safer and more controlled.
  • Boundary testing: You can test edge cases, such as reversal scenarios or preAuth scenarios, which may not be easily achievable in a live environment.

Remittance exchange rate

The remittance exchange rate plays a crucial role in ensuring accurate and reliable transactions, making it essential to test through both integration testing and regression testing. Here’s why:

Integration Testing

  • Transaction Submission Process: The exchange rate response is mocked within our system. Transaction submission involves interactions between multiple components, making it necessary to ensure seamless integration.

Regression Testing

  • Real User Workflow Impact: The exchange rate directly influences the destination amount calculation, a critical aspect of the transaction process. End-to-end regression testing works in the same way as the app using the exchange rate logic and access the rate DB.

User Email Change Bug

In the user email change bug, when a user changes their email, the user profile email is updated even if the new email is not verified. Clearly, this is a workflow that involves interactions with multiple APIs, but the lowest level at which the test can be implemented is the integration testing.

Integration Testing

We have already added the integration tests to ensure it doesn't reoccur and introduce assertions to validate the behavior.

MPay Regression test

MPay is a critical but simple feature, and it only has two happy path regression test scenarios, which the team has agreed are sufficient.

The first test is 'Send MPay', which covers transferring money between Majority accounts. The second is 'Internal Transfer', which handles money transfers between a user's pocket account and their primary account.

We just need to keep in mind that when introducing CFSB as a new type of Majority user, additional considerations or tests might be required.