4 ms·

For those using Selenium or something similar, do you have any tips for making test suites fast? Usually I just test the main flows with Selenium, then go more

For those using Selenium or something similar, do you have any tips for making test suites fast? Usually I just test the main flows with Selenium, then go more indepth with unit-tests where parts of the application are mocked out - but it's a trade off between accuracy and speed.

vojant 10y ago
Run tests in parallel, only way too make it fast.
cstejerean 10y ago
That's a good trade off though, and not just for speed. Selenium tests are more difficult to write and take more effort to maintain. You should definitely test as much of your application as you can with unit tests and integration tests. The end to end tests with something like Selenium should then focus on the type of bugs that you couldn't catch with the lower level tests. I've seen situations where people had Selenium tests for every possible validation error on a form. A lower level test would have been sufficient to test all validation permutations and making sure they return the right error message, and then a single high level test can ensure that when an error message is returned it is properly rendered on the screen.
markoa 10y ago
I'd advise definitely covering all usage scenarios with Selenium. And then parallelize. Overall unit tests should greatly outnumber UI/integration/acceptance tests. And when you catch a bug with Selenium test, replicate it at the right place with a unit test. Look up "test pyramid" if you're perhaps not familiar with it.
dhpe 10y ago
- Test cases should be designed to allow parallel execution (they should not interfere with each other) - Do not use sleep() for synchronisation - use explicit waits (e.g. wait until element is visible, then proceed immediately)
blktiger 10y ago
If you haven't encountered the concept before, I recommend looking at the testing pyramid[1]. Basically the idea is that UI/Functional tests take a long time to run so you want just enough to test the main, important flow in the application while you want a ton of unit tests because they run quickly and give you very targeted feedback about what might be broken. [1] https://martinfowler.com/bliki/TestPyramid.html https://martinfowler.com/bliki/TestPyramid.html

vojant 10y ago

Run tests in parallel, only way too make it fast.

cstejerean 10y ago

That's a good trade off though, and not just for speed. Selenium tests are more difficult to write and take more effort to maintain. You should definitely test as much of your application as you can with unit tests and integration tests. The end to end tests with something like Selenium should then focus on the type of bugs that you couldn't catch with the lower level tests. I've seen situations where people had Selenium tests for every possible validation error on a form. A lower level test would have been sufficient to test all validation permutations and making sure they return the right error message, and then a single high level test can ensure that when an error message is returned it is properly rendered on the screen.

markoa 10y ago

I'd advise definitely covering all usage scenarios with Selenium. And then parallelize. Overall unit tests should greatly outnumber UI/integration/acceptance tests. And when you catch a bug with Selenium test, replicate it at the right place with a unit test. Look up "test pyramid" if you're perhaps not familiar with it.

dhpe 10y ago

- Test cases should be designed to allow parallel execution (they should not interfere with each other) - Do not use sleep() for synchronisation - use explicit waits (e.g. wait until element is visible, then proceed immediately)

blktiger 10y ago

If you haven't encountered the concept before, I recommend looking at the testing pyramid[1]. Basically the idea is that UI/Functional tests take a long time to run so you want just enough to test the main, important flow in the application while you want a ton of unit tests because they run quickly and give you very targeted feedback about what might be broken. [1] https://martinfowler.com/bliki/TestPyramid.html https://martinfowler.com/bliki/TestPyramid.html