Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

First Episode #8

Open
IonFoXx opened this issue Jul 8, 2020 · 2 comments
Open

First Episode #8

IonFoXx opened this issue Jul 8, 2020 · 2 comments

Comments

@IonFoXx
Copy link

IonFoXx commented Jul 8, 2020

Hi expect(Exception) Crew,

first of all, thank you for providing this awesome kind of podcast. I was half way through the first episode and got immediately hooked on the topic.
I've been using cypress a few times for all kind of differently sized projects and found it awesome to work with and would definitely recommend it at least to giving it a try. It is also very easy to integrate into a CI / CD pipeline.

On the topic of E2E testing though I have a few things that I never found a good answer for. So maybe you can help me and others out with those.

Topic 1 - Large Test Setups:
What are your recommendations about large websites and E2E Testing. I always find it kind of hard to provide the correct test setup for those E2E tests.
As an example lets say you have a 1 TB ElasticSearch Cluster and need to restore it to do the E2E tests and keep it at least up to date every now and than. A restore could take hours before the test could even start. Not even talking about the resources need to run the tests. It also seems that the tests get very generic as the provided test data changes every now and than. Would you recommend to only restore a subset or create a test data set that covers most of the cases. But that than sounds like mocking and I think Dave, I hope I got the name correctly, meant it would be better to test with a correct "real" setup.

Topic 2 - Test Security and Setup:
What about third party systems where you would need to provide API Keys to access the data. Where to store those information how inject them into the test setup?

Topic 3 - 3rd Party Tools:
More complicated flows where third party tools, not in your control, are involved are getting very complicated. For example registration forms where an email is send to the a mail box and the account needs to be verified with a token. Are there any recommendations?
I tried this once and got it working by using a JSON based mailbox and parse the verification link out of the email. Was working great than but are there any better solutions?

Topic 4 - Device Tests vs. E2E Tests:
You also mentioned the lack of device variety in Cypress. As far as I understand E2E tests, there is no need to test all possible devices and browsers. For those kind of test you should run automated device tests provided through tools like BrowserStack aso. Is this correct, are there recommendations or would you say that an E2E Test needs to include a wide device variety otherwise it is no real E2E test.

As said before awesome topic you picked for creating a podcast with it so keep going!

Best regards,
Helmuth

@Vannsl
Copy link
Member

Vannsl commented Jul 8, 2020

Hey Helmut,

thank you for your kind words, you made each of us smile :)

Topic 2:
It may depend on the level of security you need in your repository. For environment variables, it's possible to create a cypress.json file and run cypress with e.g. cypress open --config-file specs/cypress-config.json.

The downside is that your repository either needs to be private or the cypress.json has to be added to the .gitignore file and shared using a secure way between the developers. (There are some alternative approaches, explained here: https://docs.cypress.io/guides/guides/environment-variables.html#Option-3-CYPRESS

On top of that, you're using a CI tool where cypress runs, it should be possible to add the env variables inside of the CI tool.

Best
Vanessa

@IonFoXx
Copy link
Author

IonFoXx commented Jul 9, 2020

Hi Vanessa,

thank you for your response and I'm glad I made the crew smile.

Your solution would nicely integrate, at least I think, with a secret store like HashiCorp Vault or AWS Secret Store. There you could store the credentials needed and a prepare script could download the needed information. Really nice input.
I guess it would also be compliant with a high security standard as you could rotate the stored information every week, day, hour or minute to invalidate Api keys and still make it easily usable for local testing or automated testing. Thanks!

Best regards,
Helmuth

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants