Initial commit of cypress

[pboyd04]

Based off your https://github.com/BurningFlipside/DevSandbox/pull/91/files

[russelltsherman]

it is my opinion that the cypress tests should live in an independent repo.
not alongside the source as unit tests typically do.
this will facilitate significantly DRYer cypress test code.

i find it to be less effort to check out a separate repo to run and maintain integration tests compared to having to change shared code across multiple repos when things inevitably change.

[pboyd04]

While I agree there is some amount of boiler plate test code that will have many common elements across several projects such as login. But that is the exception and not the rule. 90+% of the functionality is different.

Additionally, this is how most people are used to writing test code. And I know of at least 2 external groups that are interested in using the volunteer system but not other aspects of our codebase. I'm hopeful that more people using the code will help make it better and encourage contribution, but only if we don't make it too difficult to contribute. I've mostly got Volunteer system to the point where all you have to do is clone the repo and run composer install to try and make it easier to use.

However, if you feel strongly about the test code being in a separate repo I can get behind that assuming we can meet 2 criteria:

1. The test code needs to be able to be run for specific environments without code alteration (i.e. environment variables or config files that aren't checked in to git) and not specific to the DevSandbox environment. This will allow external groups to use it and for us to use the tests on things like the gate server which is purposefully configured differently.
2. While everyone should run the tests on their own setup before committing code we also need CI. So whatever we do needs to be able to function in a CI environment. As has become obvious from the DevSandbox stuff our environments are vastly different and even if I get DevSandbox to work its not clear that it will function identically. It's also possible that a certain value in a DB somewhere could change code behavior. Having CI allows us to have an independent arbiter to say that the code is indeed correct.

[russelltsherman]

if people are really going to use one of our applications and nothing else.. then maybe dividing the test code is ideal.. for some of the duplication will be as you say.. login actions.. but you will find yourself writing various helper functions and wanting to keep them in sync across project repos.. npm could be used for this purpose..

cypress tests will work best then they are exercised against an ephemeral environment.. that is why running them from the docker compose symphony in the sandbox project is an ideal scenario.. in that scenario the tests can be faithfully executed against a known starting data set and without expecting the user to modify any settings..

alternately cypress can be targeted to any accessible web service.. but then you have to set the base url env var to make that happen.. running the tests outside the sandbox means you the user are responsible for setting up all the required applications and services under test.. and targeting any long running stateful service will almost assuredly result in brittle tests due to changing data sets..

it's a terrible idea to run cypress against a production environment as it makes real changes in your persistence layer.
it's costly to run a dedicated test environment and then again.. cypress is making real changes to your persistence layer and lacks the ability to reset the persistence layer between executions..
a sandbox is the ideal environment for this testing because it can be easily and predictably reset..

the same docker compose definition of the sandbox project could be executed in just about any CI service which supports docker..