Proposal: Support for "first class" Unit Tests

To date Cypress has always represented itself as an integration / e2e testing tool.

Nearly all of the cy commands drive the browser in this manner.

Almost There However with automatic ES2015 support we are also tantalizingly close to being able to add first class unit testing support. This would enable users to import their application specific libs and test them in Cypress.

Thinking Ahead And in fact the entire reason we created a cypress/integration folder is so that we could add unit testing support alongside this as cypress/unit. By distinguishing these two types of tests means that Cypress could handle them both differently and optimize against each.

Today’s workaround As it stands right now, and as per the cypress-example-recipes you currently just write “unit tests” alongside your integration tests.

But this is not ideal for several reasons:

The problems

• Unit tests are just different than integration/e2e tests. Currently we enforce a certain lifecycle to integration tests - meaning between the tests we do things like clear cookies, local storage, and tear stuff down. This has no place in a unit test and is a massive waste of CPU clock cycles and network traffic. In other words, unit tests won’t run nearly as fast in this manner.
• There is no concept of visiting the application in a unit test. For instance the default view before you cy.visit makes no sense. Perhaps we could repurpose this area as like a “scratch-pad” of sorts for tossing HTML into that does still get torn down between tests.
• Most of the cy commands are useless, but others are still really helpful. cy.spy, cy.stub, cy.fixture could all still be used.
• Handling things like coverage reports would be possible to automatically since a unit test inlines all of the JS files, whereas an integration/e2e test does not.
• Likely sourcemaps could be “on” by default in a unit test.
• We could possibly add more commands like cy.render which takes an HTML string and “renders” it to the scratchpad area.

[jhanink]

is there demand for this? I would love to see “first class” unit test support.

[Vandivier]

I do like the ability to measure coverage which has a separate issue filed, but one issue which doesn’t fall under that scope and I think does fall under the scope of first class unit test support is folder structure. I don’t merely want to separate /cypress/integration from /cypress/unit, I want to be able to have my spec files in the UI component folder and have cypress run those.

That is a convention for UI unit testing and it facilitates moving components between apps. It also removes the existence of monolithic UI app tests. Consider the structure of phonecat demo app for example:

https://github.com/cypress-io/cypress-example-phonecat/tree/master/app/core/checkmark