I don't back the point of having e2e test cases less than a minute.
Let's talk about practical scenarios like...
Account creation
Application setup
Order payment flow ...
How in the world can we have e2e tests that too UI tests take less than a minute ..
Its the ground reality .. We can set up few tests with some seeded data.
But end of the day there are going to be long running user flow test cases in any typical automation suite
Thanks for the feedback! I agree with your point that not all tests can be less than a minute and that's why I said "ideally" try to keep it less than a minute. The main focus is to make your test do 1 thing instead of mixing multiple flows together.
In some of the examples above, I've seen people do this ->
Account creation
App setup
Order payment flow
All these in 1 test when they wanted to only test the payment flow and that ends up making your test around 4-5 mins now. So, we need to be careful of such scenarios when writing e2e tests.
And, to your point "How in the world can we have e2e tests that too UI tests take less than a minute .." - with majority of the JavaScript frameworks nowadays, tests runs extremely fast and if setup properly by taking advantage of app state + mocked/seeded data, you can easily keep them under a minute including the flows you have mentioned above.
Still, the point of the article is not the "time" of the tests but more so knowing what exactly your tests are doing. If you can have long running stable tests and it works for you and your team then that's what matters at the end of the day.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I don't back the point of having e2e test cases less than a minute.
Let's talk about practical scenarios like...
Account creation
Application setup
Order payment flow ...
How in the world can we have e2e tests that too UI tests take less than a minute ..
Its the ground reality .. We can set up few tests with some seeded data.
But end of the day there are going to be long running user flow test cases in any typical automation suite
Thanks for the feedback! I agree with your point that not all tests can be less than a minute and that's why I said "ideally" try to keep it less than a minute. The main focus is to make your test do 1 thing instead of mixing multiple flows together.
In some of the examples above, I've seen people do this ->
All these in 1 test when they wanted to only test the payment flow and that ends up making your test around 4-5 mins now. So, we need to be careful of such scenarios when writing e2e tests.
And, to your point "How in the world can we have e2e tests that too UI tests take less than a minute .." - with majority of the JavaScript frameworks nowadays, tests runs extremely fast and if setup properly by taking advantage of app state + mocked/seeded data, you can easily keep them under a minute including the flows you have mentioned above.
Still, the point of the article is not the "time" of the tests but more so knowing what exactly your tests are doing. If you can have long running stable tests and it works for you and your team then that's what matters at the end of the day.