Move unit tests to src

[christopher-johnson]

this PR is preparation for moving the integration tests to cypress. the unit tests will live in src and the integration tests will live in a new directory called cypress in the <rootDir>.

[sdellis]

Thank you for your work on this, @christopher-johnson ! We reviewed this yesterday, and are definitely 👍 on the test coverage commit.

I think we were confused as to why the unit tests got moved, but not the integration tests, which is why we hesitated to merge. I just noticed your comment here about leaving integration tests where they are until cypress is introduced.

So at this point, I am 👍 on this PR now. @mejackreed and @aeschylus do you have any further reservations before merging this?

[mejackreed]

My inclination is to keep all of the tests in the same place. If we move to Cypress (or something else), is there a way to keep these things all together rather than split them up?

[christopher-johnson]

the unit tests test the components and should definitely be in the src directory and use jest. typically, integration tests are completely different in scope and purpose, and will not use the same test framework. I personally do not see any reason why they should be combined.

[mejackreed]

My reasoning for keeping them in the same place is just really about convenience and consistency. If all of the tests live in the same place, I don't have to go hunt them down in multiple places. I think that "end to end", "integration" and "feature" testing at some point here will blend together. And the purity of an end to end test may be mixed up with need to test interaction between components.

All this being said, I don't feel that strongly about either approach. Just wanting to share my reasoning for keeping things together. I realize that communities, languages, all have different existing practices on this. Hopefully we can come together on one that works for us!

[christopher-johnson]

Admittedly, I have a bias towards component based architecture and strong encapsulation being a Java programmer. And, I really believe that defining clear boundaries is essential for an application to grow properly. While separations are sometimes inconvenient, a modular code base is generally more flexible and extensible. And everybody wins with that. Not sure what sort of consistency you refer, but if style rules exist and there are governing APIs, then consistency can readily be managed across package and functional boundaries.

What is a unit test is quite clear, though I agree that the terminology for the varieties of "browser based testing" are not so clear. What should be avoided is to run unit tests in a global browser testing environment, which is what I suspect is the current situation with the preset jest-puppeteer.