Running AppConnect Recipes: Test

Test mode

AppConnect has an integrated build and test environment to enable users to test their Recipes soon and frequently in the development process.

To enter the Test Mode, move the “Recipe/Test Jobs” slider to the “Test Mode”. Return it to “Recipes” to re-enter the build / edit mode.

31b48ba7-f12a-4eee-aa37-794152c622f9.png

It is best practice to test your Recipe before starting it and letting it run with minimal supervision. You don't want to turn on inaccurate automation that moves and processes data wrong - that probably requires a lot of cleanup!

The test Recipe button picks up a single trigger event and runs it through your Recipe to create a job. This lets you review the job details to check for Recipe correctness.

Test trigger events

The trigger event picked up when you select test depends on the When first started, this Recipe should pick up events from configuration selected.

In the following example, clicking on test will have the Recipe look for Box folders created or updated after 1 Feb 2019, midnight.

If the Recipe test mode finds Box folders matching that criteria, it proceeds to process the first trigger event in the queue.

As trigger events are processed in chronological order, the account created or updated earliest (closest to 1 Feb 2019, midnight) will be processed.

0d44c1af-4aaa-44b4-ae06-e27ec936db1e.png

The Since or From setting enables Recipes to fetch past trigger events from a specified date and time. i.e. instead of picking up new trigger events (events created since Recipe was started) this enables picking events that have already occurred.

Remember, the Since/From date cannot be changed once you have tested/started the Recipe!

If you enter the Test Mode without setting up a trigger, it will display the following message:

27e70b64-c202-4145-808a-6eac51898b3b.png

If you enter the Test Mode without conducting a test of your Recipe, it will display the following message:

3e74b655-a1ef-4490-b010-387739292cdf.png

When a test is in progress, the following message will be displayed:

17c15128-98d9-4f94-9ab5-480cc954459c.png

Cancelling a test job

You can cancel a test job by clicking on the cancel button in the test mode. The following message will be displayed while the job is being canceled.

8c710d1e-4d31-45f4-b1d8-5ed279139ed2.png

Test Results

If your test is successful, you will be able to see the test path of the Recipe run as well as the Input, Output and Debug information in the Test Mode. Please refer to the following example of a successful test run.

de39fa71-8312-4341-afc6-0c586337afae.png

If a test run is not successful, the Test Mode will display the step at which the error occurred and a description of the error. The step at which the Recipe failed will be highlighted. Click on the step to view details.

9428d961-d074-4ffe-a385-4a6d61ef7fdc.png

You can fix the errors in build mode before choosing to repeat the test job.

Test jobs and repeat jobs

A test job is a job conducted in a testing environment that uses new trigger data from the trigger application. Conducting a new test job uses new trigger data. A repeat job is one where the same trigger data is reused for conducting the test. AppConnect allows the user to conduct new test jobs as well as repeat jobs. The Test Mode displays both the test job number as well as the repeat number (if the test has been repeated) for any test conducted on a Recipe.

In the following example, the results for test job number 4998818868 and repeat number 1 are displayed.

a8428187-be86-4920-901e-c8df07047173.png

You can access previous test jobs by using the drop down menu provided.

c550fd5d-053e-4192-b5b1-982c0e029725.png

View all past jobs

For a full list of test jobs, please click on see all test jobs for a view of the job table.

6592052e-f974-4276-a806-46ab2391dd24.png

Similarly, the repeat history for any test job can be found at the drop-down menu for repeat jobs.

0c86cba0-9cb7-4416-9b23-29779c68c075.png

 

Testing tips

Use sandboxes

As best practice, try to use sandboxes instead of production accounts for testing Recipes. This ensures that you're using realistic data but not working with production, possibly mission-critical data.

Build your Recipe incrementally

Build your Recipe incrementally and test at logical intervals. Building and testing small segments of the Recipe at a time ensures that the Recipe flow is coherent and the datapills are mapped properly. It also makes debugging easier.

Build your Recipe incrementally with skip step. Skip steps allows you to ignore steps when running a Recipe. This is very useful when you’re trying to build a Recipe and only want to test a part of it.

Test all possible scenarios

Recipes often come with multiple lines of conditional logic. Check that there are no missing conditions in your Recipe flow. For example, handing cases where Emails is present and when it is not present.

Test all mapped data fields and pills

To ensure data is being transformed (if applicable) and moved from one app to the other correctly, test all data being moved.

 

Was this article helpful?