Ui testing

[croor005]

Fixes #{issue number here}

• Up to date with dev branch
• Branch name follows guidelines
• All PR Status checks are successful
• Peer reviewed and approved

Any questions? See the getting started guide

[jmensch1]

Hey Rich! Great stuff. I don't have any comments on the actual Cypress code, but there are a couple things I'm hoping we can do to get your testing apparatus better integrated into the codebase and into our CI process. I'm not sure how hard these things are, so maybe we can do a zoom chat at some point and discuss this stuff.

1. Separate cypress code from the frontend

It would be ideal if the Cypress stuff were totally distinct from the frontend codebase. In particular, this would mean:

1. the /cypress directory gets its own package.json so that it can be installed and run separately from the frontend. The package.json would include only the dependencies related to Cypress (which can then be removed from the frontend package.json). And also any Cypress commands (like the cypress open command and any others we add later) can be triggered from the /cypress directory as well.

2. the /cypress directory also gets its own .gitignore.

2. Extract environment variables from cypress code

I noticed a couple of magic strings in your code that would ideally be put into the environment. These are the ones I'm talking about (and I may have missed some):

1. CYPRESS_RECORD_KEY -- this can easily be put into a Github secret

2. MAILOSAUR_API_KEY -- I see this is in the config.js file. Not sure if there's a way cypress can read from the environment (like a .env file or Github secret) to get this value. Possibly also the projectId although I'm not sure it's necessary.

3. The serverId and testEmail in cypress/integration/email.spec.js

4. the stuff in cypress_api.spec.js

    Cypress.env({
      host: 'veronica.dev.local',
      api_server: 'http://localhost:8888/v1/',
    })

3. the email issue

We talked about how the tests are currently creating real issues on the issues board and sending emails to the 311-data gmail account. I can put a flag in the backend so that tests on dev use a different email for testing. Not sure how to handle the issues board yet -- maybe we create a separate board for testing although that does seem like a hassle.

4. unused tests?

I'm not sure if all the tests in the code are actually running yet? Some of them looked like they may just be part of a standard Cypress package and maybe aren't hooked up. If so, it would be nice if there was a way to distinguish the active tests from the ones that aren't working yet.

Thanks much, talk soon.

[croor005]

1. Separate cypress code from the frontend Sure it should be possible to separate it out. The reason Cypress normally lives in the same repo as that makes it easier to trigger the tests in CI. Are you suggesting an altogether separate repo or a different folder structure? 2. Extract environment variables from cypress code Right. As a "quick and dirty" solution I just plopped them there but yes I'll move them out to ENV 3. the email issue Yeah this will take a little more digging. Cypress comes with the ability to use fixtures which act as mock network stubs. So instead of sending the request to your backend when form submission occurs we can intercept that behavior. 4. unused tests? By default I turned off the tests and all it takes to turn them on is to remove the "it.skip..." to "it" in the test itself. The ones in the example folder can be removed without issue or we can just skip them all. Thanks! See ya tonight... Rich

…

On Wed, Jul 29, 2020 at 10:10 AM Jake Mensch ***@***.***> wrote: Hey Rich! Great stuff. I don't have any comments on the actual Cypress code, but there are a couple things I'm hoping we can do to get your testing apparatus better integrated into the codebase and into our CI process. I'm not sure how hard these things are, so maybe we can do a zoom chat at some point and discuss this stuff. 1. Separate cypress code from the frontend It would be ideal if the Cypress stuff were totally distinct from the frontend codebase. In particular, this would mean: 1. the /cypress directory gets its own package.json so that it can be installed and run separately from the frontend. The package.json would include only the dependencies related to Cypress (which can then be removed from the frontend package.json). And also any Cypress commands (like the cypress open command and any others we add later) can be triggered from the /cypress directory as well. 2. the /cypress directory also gets its own .gitignore. 2. Extract environment variables from cypress code I noticed a couple of magic strings in your code that would ideally be put into the environment. These are the ones I'm talking about (and I may have missed some): 1. CYPRESS_RECORD_KEY -- this can easily be put into a Github secret 2. MAILOSAUR_API_KEY -- I see this is in the config.js file. Not sure if there's a way cypress can read from the environment (like a .env file or Github secret) to get this value. Possibly also the projectId although I'm not sure it's necessary. 3. The serverId and testEmail in cypress/integration/email.spec.js 4. the stuff in cypress_api.spec.js Cypress.env({ host: 'veronica.dev.local', api_server: 'http://localhost:8888/v1/', }) 3. the email issue We talked about how the tests are currently creating real issues on the issues board and sending emails to the 311-data gmail account. I can put a flag in the backend so that tests on dev use a different email for testing. Not sure how to handle the issues board yet -- maybe we create a separate board for testing although that does seem like a hassle. 4. unused tests? I'm not sure if all the tests in the code are actually running yet? Some of them looked like they may just be part of a standard Cypress package and maybe aren't hooked up. If so, it would be nice if there was a way to distinguish the active tests from the ones that aren't working yet. Thanks much, talk soon. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#760 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQJFY3ORZMTEWEEUVRNXGIDR6BJZLANCNFSM4PLEKPQQ> .

[jmensch1]

Hey Rich, sorry bout the delay. I think the most important thing to do first would be #2, since we don't want to be pushing any secrets to the repo. Once that's done we can actually deal with the other stuff later.

Regarding #1, I was just talking about creating a new package.json and .gitignore and putting them in the /cypress directory (not creating a separate repo). The idea is that the testing and frontend be totally independent and not share files or dependencies.

As for #3 and #4, sounds good.
Thanks, Jake