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

Try to parallelise the test running algorithm #22

Open
hrj opened this issue Nov 5, 2015 · 3 comments
Open

Try to parallelise the test running algorithm #22

hrj opened this issue Nov 5, 2015 · 3 comments

Comments

@hrj
Copy link
Member

hrj commented Nov 5, 2015

Currently, the test runs sequentially:

  1. Navigate to test URL
  2. Take a screenshot
  3. Compare the test and reference screenshots

If we used a simple actor system, we could do #3 in separate actor.

Down the line we could parallelize it even more:

  • Pre-fetch URLs to warm up the OS cache
  • Open more than one window in the browser, so that navigation to different test URLS could be done in parallel.
@hrj
Copy link
Member Author

hrj commented Nov 5, 2015

This could be a very cool task to pickup @atiqsayyed (when you get free).

@hrj
Copy link
Member Author

hrj commented Nov 17, 2015

@atiqsayyed

Thinking more about this: you needn't use actors; it might be simpler to use Futures with an ExecutorService. The advantage of Future is that you can chain operations together easily and let the ExecutorService do the scheduling.

This is a very high level sketch of how this would work:

  • You would create a future task for each test. This future will in turn depend on two futures: a future for getting the screenshots and a future for comparing the screenshots.
  • All the above futures would be added to a queue.
  • The main thread will pickup the first future in the queue and then wait for its completion. After completion, it will update the status (progress bar, etc) and then pickup the next future.

Hint: the webdriver object will need to be locked till both the screenshots are acquired. Alternatively, the future for getting screenshots should be scheduled on a single threaded executor-service.

@atiqsayyed
Copy link
Contributor

@hrj this is cooooool. . . I'm picking it up!

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

No branches or pull requests

2 participants