Skip to main content

Dry Running E2E Test Functions

Dry Run feature of IDE allows you to run tests written in ZWL without running a browser (and a VM). This is specially helpful while you're learning ZWL and want to verify language specific operations before running tests on a VM.

When a ZWL test contain e2e test functions, dry running requires little additional work from you. This is because e2e test functions requires a browser to run whereas dry run doesn't use a browser.

When you dry run a test:

  • E2E test functions that don't return a value will remain quiet and won't do anything.
  • E2E test functions that return a value will return a default value of compatible type. For instance, string returning functions such as findElement return a sample string value, number returning functions such as getTimeout returns a sample number, boolean returning functions such as colorMatches returns true/false, map returning functions such as getWinPosition return sample x, y coordinates as map, list returning functions such as findElements return sample ids as list.

Your test may or may not work with default values depending on what you're doing with the return values of those functions.

If we dry run a test similar to the following example, it will fail because the default value of getElementText isn't what we're trying to compare it with.

assertTrue(81 == getElementText(findElement('total', by.testId)))# fails with dry run

But that doesn't mean we can't dry run this test. ZWL has a special syntax to stub e2e test functions with the desired value that will be returned instead of the default one. Let's see how that syntax looks like by fixing the above test for dry running:

assertTrue(81 == getElementText(findElement('total', by.testId)) ?? { '81' })# dry run passes

This fixes our test for dry run. We've stubbed findElement with the value we required i.e 81 making sure that it is compatible with the return type of the function which is string. If we don't stub a type compatible value, a type error will be thrown upon dry running.

Syntax for stubbing#

FUNCTION_CALL ?? { STUB_VALUE_OF_COMPATIBLE_TYPE }

note

If you stub a function's return value, it will be read only when dry running and ignored during builds. Therefore there is no harm in keeping it in tests.