Skip to main content

Component Testing

The Component Test sits in the middle layer of the Testing Pyramid. This test type evaluates the expected data result of an isolated component. In a Mendix application, a component represents a cohesive set of microflows that collectively implement a specific piece of functionality. Components can vary from small orchestrations of a few units to a large, reusable module.

Regardless of its size, a component typically has too many possible input combinations for exhaustive testing. Therefore, component testing focuses strategically on a limited set of scenarios that are high-risk, business-critical rather than on full edge-case coverage.

While the scope of this test has similarities with an integration test and a unit test, its focus is different. An integration test checks whether the called units run in the right order and follow the correct flow. A unit test checks the data results for all edge cases of a unit microflow. In contrast, the component test focuses only on confirming the final data output of the transaction, using a limited number of edge cases.

1. Creating a Component Test​

Creating a robust component test involves a structured approach:

  1. Identify Component Boundaries: A component is typically defined by its public interface, meaning the set of microflows that are intentionally exposed and allowed to be called from outside the component. Identify which of these entry-point microflows you intend to test.
  2. Define Critical Scenarios: Unlike a unit test, where the goal is to test all possible boundary values, component testing focuses exclusively on critical, end-to-end business scenarios. This selection must include the "happy path" (successful process) and a few essential failure paths.
  3. Provide Test Data: To test the component in isolation, it must be supplied with the necessary input data. This provision might involve creating specific data directly in the database using a test fixture, or passing required objects as parameters to the component’s top-level microflow.
  4. Execute the Test: Run the component's entry microflow for each defined critical scenario using the prepared test data.
  5. Define Asserts: Add assertions to validate that the final data result aligns with expectations. This validation involves checking the return value of the microflow or examining the final state of objects persisted in the database.

2. Component Test Example​

Consider a component responsible for managing a customer’s subscription request. The process is initiated when a touchpoint microflow triggers the orchestration microflow, ORC_subscription_request. This orchestration, in turn, calls several sub microflows to validate customer data, process payment, and update the subscription status. Instead of unit-testing each of these internal microflows individually, a component test validates the outcome of the ORC_subscription_request as a unified whole

Component test: Subscription Request
  • Scenario 1: Successful Subscription. Provide the system with valid customer data and a valid credit card. The corresponding assert must verify that the subscription status is set to "Active" and that a payment record has been successfully created.
  • Scenario 2: Failed Payment. Provide valid customer data but intentionally use an invalid credit card. The assert should confirm that the subscription status is set to "Payment Failed" and that no payment record was created.
  • Scenario 3: Invalid Customer Data. Provide the system with missing or invalid customer data. The assert should check that the microflow returns an error message and that the database remains unchanged.