lundi 24 décembre 2018

Front-end E2E testing: benefits of real and mock data

I just started writing front-end e2e tests for my app. The app has front-end core and back-end API. I doesn't matter what frameworks I have, the question is about general principle.

I'm standing in the middle of two approaches - mock outgoing HTTP requests or not.

So the most resources says that I should mock all outgoing HTTP requests and I don't like this approach, here is why - it feels like not a e2e at all. In this case, if something has been changed on back-end side it wont reflect on front-end side. I have tests for my back-end as well though. Lets say I had to implement some feature to an existing back-end code. So I did the feature and fix related back-end tests and forget to made all required changes on front-end side. In this case all tests are green, but the app is broken at the same time.

In my app I've started the second approach - not to mock any HTTP requests. In this case if I done some changes to back-end side - front-end e2e tests will fail as well. But now I have the following problem - I can't launch more than one stream of tests against the same database, because it may cause a collision. So this is a huge performance issue.

Here are my thoughts, I don't know what are the best practices nowadays, so I asking for an advice - can someone explain which approach is better? What I'm missing? Please, share your experience.




Aucun commentaire:

Enregistrer un commentaire