davidmhatton

Debugging a single cy test

Ever tried getting debug output from within a component during a cypress run? You've probably noticed you can get lots of iterations of the output that are of no interest as you've only wanted to debug one test. This little snippet shows how to conditionally render output depending on which test is running by making the test name known to the subject component via the window.

Shown here is a fictional MyComponent with a corresponding test suite. By default, using console.debug("hello!"); within the subject (component) code would yield multiple iterations of "hello!" with no reference to which test case is being examined.

By passing the knowledge of which test is running into the global window, the subject code that is being run by the cypress-mounted component can have access to that crucial context, allowing conditional logging. That permits the engineer to output sensible quantities of debug data only when the test of interest is being conducted, and all other tests will

davidmhatton

Propchanges Design Pattern

The idea behind this pattern is that there is a customMount function at the top of the test that allows the user to create a mounting scenario by passing a subset of props -- specifically, only the props that they wish to modify. Any props that are not passed to the function either remain un-given to the component, if optional, or with their default value if mandatory. Any props specified in the call to customMount will be provided as-specified regarless of whether they are mandatory or not, or of their default values.

customMount(); // mounts the component with default values of minimum props only
cusotmMount({ prop1, prop3, prop5 }); // mounts the component with specified values of prop1, prop3, and prop5 and default values for all others.