Component Testing and Documentation guide

When do we need to test components?

After a component, usually a connector or loader to a new platform has been developed, the dev team will require an analyst, usually the analyst working on the project that requires said component, to test the component.

What do we need to prepare before testing components?

It depends on the individual project requirements and platforms we’re integrating with, but in general, you want to have these few things in mind before you begin testing:

• Credentials and access to the platform, typically this will be a UI on the web, though it may come in different forms.
• Credentials for programmatic access to the platform, this would usually be credentials for an API. The component should be already built with the appropriate configuration parameters to input the credentials.
• If the authentication method requires OAuth, the OAuth repository will be set up in the Meiro Integrations instance you are testing the component on.
• Basic understanding about the platform, so you know where and what data you want to get from it in the case of a connector, and where and what data you want to send to it in the case of a loader.

You also want to try to prepare data - even if it’s just simulated data - that resembles customer’s data as closely as possible:

• Data volume:  e.g. If the customer/use case will operate on GB scale, we should do at least some tests with GB of data, to understand runtime behavior and performance. We want to avoid performance surprises in production.
• Data types: e.g. do not test on trivial/ideal data, but use something resembling real data (typos, special characters, international strings, binary attachments). Do not go crazy, but use your knowledge of the solution to simulate data conditions that the component will have to deal with in the customer’s environment.

What are the steps to test a component?

Now that you have everything prepared, you are ready to test the component.

Keep these points in mind while testing the component:

Ask and test questions such as:

• What happens if the (down)load is interrupted due to a network or other problem?
• If I configure the component wrong, is the UI providing reasonable errors? Are those errors helping me to fix the configuration problems and make it work?
• If the component crashes during runtime, is the error message reasonably understandable?
• Is a loader crash causing (dangerous) system contamination? Does it leave a downstream system in a malfunctioning state? Is it deleting data from a system which will be difficult to retrieve?
• If a crash occurs and the component is part of automated processing how do we recover the failed automated run? How long does it take to recover? Does it prevent other runs from happening? Does the component need to be more error-resilient as it's used in 'dangerous' scenarios?

Think in the context of use-cases/scenarios that you know the component will have to operate in. Try to make sure we will be able to both implement and operate those scenarios in the customer environment.

General steps for testing:

1. Test the credentials for the platform - try to log in to the platform where you are trying to connect/load data. In general, there should be a UI where you can see what data you are trying to connect to, and what destination you are trying to load to.
2. Check the credentials for Meiro Integrations - in the case of OAuth authentication, test if the URL redirect is working properly and has been set up properly by the Meiro team. With other forms of credentials such as API key, token and secrets, continue to the next step.
3. Test the component - the developer working on the component will provide a testing Meiro Integrations instance to test the component with. You want to try to create the component you are testing in the instance.
   • For a connector, you want to check if the credentials in step 2 works with the connector, and if data can be obtained from the platform in a format that is workable, depending on the nature of the data it can be in the form of a .csv, .ndjson or any other format that makes sense for the specific use case.
   • For a loader, you want to check if the credentials in step 2 works with the loader, and if data can be loaded to the destination platform correctly.
4. Report any issues - report any issues that you find while testing the component to the developer working on the component and have them resolve it, after which you will test the updated component again. Repeat until no further issues are found.
5. Assist with documentation - you will be asked to help with a few pieces of documentation, depending on if it’s a connector or a loader. 
   • In the case of a connector, typically you will only need to work on the component documentation. 
   • In the case of a loader, as it is usually associated with a destination on a platform, you will need to help out on the set up guide for analysts, the component documentation, as well as a user guide for business users.