Skip to content

Commit c27ae93

Browse files
committed
Adding "when to use Grid" text from old docs to new docs
1 parent 2fae5dc commit c27ae93

File tree

6 files changed

+305
-0
lines changed

6 files changed

+305
-0
lines changed
Lines changed: 45 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,45 @@
1+
---
2+
title: "When to use Grid"
3+
weight: 4
4+
---
5+
6+
Generally speaking, there’s two reasons why you might want to use Grid.
7+
8+
* To run your tests against multiple browsers, multiple versions of browser,
9+
and browsers running on different operating systems.
10+
* To reduce the time it takes for the test suite to complete a test pass.
11+
12+
Grid is used to speed up the execution of a test pass by using
13+
multiple machines to run tests in parallel. For example, if you have a suite of
14+
100 tests, but you set up Grid to support 4 different machines (VMs or
15+
separate physical machines) to run those tests, your test suite will complete
16+
in (roughly) one-fourth the time as it would if you ran your tests sequentially
17+
on a single machine. For large test suites, and long-running test suite such as
18+
those performing large amounts of data-validation, this can be a significant
19+
time-saver. Some test suites can take hours to run. Another reason to boost the
20+
time spent running the suite is to shorten the turnaround time for test results
21+
after developers check-in code for the AUT. Increasingly software teams
22+
practicing Agile software development want test feedback as immediately as
23+
possible as opposed to wait overnight for an overnight test pass.
24+
25+
Grid is also used to support running tests against multiple runtime
26+
environments, specifically, against different browsers at the same time. For
27+
example, a ‘grid’ of virtual machines can be setup with each supporting a
28+
different browser that the application to be tested must support. So, machine 1
29+
has Internet Explorer 8, machine 2, Internet Explorer 9, machine 3 the latest
30+
Chrome, and machine 4 the latest Firefox. When the test suite is run,
31+
Selenium-Grid receives each test-browser combination and assigns each test to
32+
run against its required browser.
33+
34+
In addition, one can have a grid of all the same browser, type and version. For
35+
instance, one could have a grid of 4 machines each running 3 instances of
36+
Firefox 70, allowing for a ‘server-farm’ (in a sense) of available Firefox
37+
instances. When the suite runs, each test is passed to Grid which
38+
assigns the test to the next available Firefox instance. In this manner one
39+
gets test pass where conceivably 12 tests are all running at the same time in
40+
parallel, significantly reducing the time required to complete a test pass.
41+
42+
Grid is very flexible. These two examples can be combined to allow
43+
multiple instances of each browser type and version. A configuration such as
44+
this would provide both, parallel execution for fast test pass completion and
45+
support for multiple browser types and versions simultaneously.
Lines changed: 52 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,52 @@
1+
---
2+
title: "When to use Grid"
3+
weight: 4
4+
---
5+
6+
{{% notice info %}}
7+
<i class="fas fa-language"></i> Page being translated from
8+
English to Spanish. Do you speak Spanish? Help us to translate
9+
it by sending us pull requests!
10+
{{% /notice %}}
11+
12+
13+
Generally speaking, there’s two reasons why you might want to use Grid.
14+
15+
* To run your tests against multiple browsers, multiple versions of browser,
16+
and browsers running on different operating systems.
17+
* To reduce the time it takes for the test suite to complete a test pass.
18+
19+
Grid is used to speed up the execution of a test pass by using
20+
multiple machines to run tests in parallel. For example, if you have a suite of
21+
100 tests, but you set up Grid to support 4 different machines (VMs or
22+
separate physical machines) to run those tests, your test suite will complete
23+
in (roughly) one-fourth the time as it would if you ran your tests sequentially
24+
on a single machine. For large test suites, and long-running test suite such as
25+
those performing large amounts of data-validation, this can be a significant
26+
time-saver. Some test suites can take hours to run. Another reason to boost the
27+
time spent running the suite is to shorten the turnaround time for test results
28+
after developers check-in code for the AUT. Increasingly software teams
29+
practicing Agile software development want test feedback as immediately as
30+
possible as opposed to wait overnight for an overnight test pass.
31+
32+
Grid is also used to support running tests against multiple runtime
33+
environments, specifically, against different browsers at the same time. For
34+
example, a ‘grid’ of virtual machines can be setup with each supporting a
35+
different browser that the application to be tested must support. So, machine 1
36+
has Internet Explorer 8, machine 2, Internet Explorer 9, machine 3 the latest
37+
Chrome, and machine 4 the latest Firefox. When the test suite is run,
38+
Selenium-Grid receives each test-browser combination and assigns each test to
39+
run against its required browser.
40+
41+
In addition, one can have a grid of all the same browser, type and version. For
42+
instance, one could have a grid of 4 machines each running 3 instances of
43+
Firefox 70, allowing for a ‘server-farm’ (in a sense) of available Firefox
44+
instances. When the suite runs, each test is passed to Grid which
45+
assigns the test to the next available Firefox instance. In this manner one
46+
gets test pass where conceivably 12 tests are all running at the same time in
47+
parallel, significantly reducing the time required to complete a test pass.
48+
49+
Grid is very flexible. These two examples can be combined to allow
50+
multiple instances of each browser type and version. A configuration such as
51+
this would provide both, parallel execution for fast test pass completion and
52+
support for multiple browser types and versions simultaneously.
Lines changed: 52 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,52 @@
1+
---
2+
title: "When to use Grid"
3+
weight: 4
4+
---
5+
6+
{{% notice info %}}
7+
<i class="fas fa-language"></i> Page being translated from
8+
English to French. Do you speak French? Help us to translate
9+
it by sending us pull requests!
10+
{{% /notice %}}
11+
12+
13+
Generally speaking, there’s two reasons why you might want to use Grid.
14+
15+
* To run your tests against multiple browsers, multiple versions of browser,
16+
and browsers running on different operating systems.
17+
* To reduce the time it takes for the test suite to complete a test pass.
18+
19+
Grid is used to speed up the execution of a test pass by using
20+
multiple machines to run tests in parallel. For example, if you have a suite of
21+
100 tests, but you set up Grid to support 4 different machines (VMs or
22+
separate physical machines) to run those tests, your test suite will complete
23+
in (roughly) one-fourth the time as it would if you ran your tests sequentially
24+
on a single machine. For large test suites, and long-running test suite such as
25+
those performing large amounts of data-validation, this can be a significant
26+
time-saver. Some test suites can take hours to run. Another reason to boost the
27+
time spent running the suite is to shorten the turnaround time for test results
28+
after developers check-in code for the AUT. Increasingly software teams
29+
practicing Agile software development want test feedback as immediately as
30+
possible as opposed to wait overnight for an overnight test pass.
31+
32+
Grid is also used to support running tests against multiple runtime
33+
environments, specifically, against different browsers at the same time. For
34+
example, a ‘grid’ of virtual machines can be setup with each supporting a
35+
different browser that the application to be tested must support. So, machine 1
36+
has Internet Explorer 8, machine 2, Internet Explorer 9, machine 3 the latest
37+
Chrome, and machine 4 the latest Firefox. When the test suite is run,
38+
Selenium-Grid receives each test-browser combination and assigns each test to
39+
run against its required browser.
40+
41+
In addition, one can have a grid of all the same browser, type and version. For
42+
instance, one could have a grid of 4 machines each running 3 instances of
43+
Firefox 70, allowing for a ‘server-farm’ (in a sense) of available Firefox
44+
instances. When the suite runs, each test is passed to Grid which
45+
assigns the test to the next available Firefox instance. In this manner one
46+
gets test pass where conceivably 12 tests are all running at the same time in
47+
parallel, significantly reducing the time required to complete a test pass.
48+
49+
Grid is very flexible. These two examples can be combined to allow
50+
multiple instances of each browser type and version. A configuration such as
51+
this would provide both, parallel execution for fast test pass completion and
52+
support for multiple browser types and versions simultaneously.
Lines changed: 52 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,52 @@
1+
---
2+
title: "When to use Grid"
3+
weight: 4
4+
---
5+
6+
{{% notice info %}}
7+
<i class="fas fa-language"></i> Page being translated from
8+
English to Japanese. Do you speak Japanese? Help us to translate
9+
it by sending us pull requests!
10+
{{% /notice %}}
11+
12+
13+
Generally speaking, there’s two reasons why you might want to use Grid.
14+
15+
* To run your tests against multiple browsers, multiple versions of browser,
16+
and browsers running on different operating systems.
17+
* To reduce the time it takes for the test suite to complete a test pass.
18+
19+
Grid is used to speed up the execution of a test pass by using
20+
multiple machines to run tests in parallel. For example, if you have a suite of
21+
100 tests, but you set up Grid to support 4 different machines (VMs or
22+
separate physical machines) to run those tests, your test suite will complete
23+
in (roughly) one-fourth the time as it would if you ran your tests sequentially
24+
on a single machine. For large test suites, and long-running test suite such as
25+
those performing large amounts of data-validation, this can be a significant
26+
time-saver. Some test suites can take hours to run. Another reason to boost the
27+
time spent running the suite is to shorten the turnaround time for test results
28+
after developers check-in code for the AUT. Increasingly software teams
29+
practicing Agile software development want test feedback as immediately as
30+
possible as opposed to wait overnight for an overnight test pass.
31+
32+
Grid is also used to support running tests against multiple runtime
33+
environments, specifically, against different browsers at the same time. For
34+
example, a ‘grid’ of virtual machines can be setup with each supporting a
35+
different browser that the application to be tested must support. So, machine 1
36+
has Internet Explorer 8, machine 2, Internet Explorer 9, machine 3 the latest
37+
Chrome, and machine 4 the latest Firefox. When the test suite is run,
38+
Selenium-Grid receives each test-browser combination and assigns each test to
39+
run against its required browser.
40+
41+
In addition, one can have a grid of all the same browser, type and version. For
42+
instance, one could have a grid of 4 machines each running 3 instances of
43+
Firefox 70, allowing for a ‘server-farm’ (in a sense) of available Firefox
44+
instances. When the suite runs, each test is passed to Grid which
45+
assigns the test to the next available Firefox instance. In this manner one
46+
gets test pass where conceivably 12 tests are all running at the same time in
47+
parallel, significantly reducing the time required to complete a test pass.
48+
49+
Grid is very flexible. These two examples can be combined to allow
50+
multiple instances of each browser type and version. A configuration such as
51+
this would provide both, parallel execution for fast test pass completion and
52+
support for multiple browser types and versions simultaneously.
Lines changed: 52 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,52 @@
1+
---
2+
title: "When to use Grid"
3+
weight: 4
4+
---
5+
6+
{{% notice info %}}
7+
<i class="fas fa-language"></i> Page being translated from
8+
English to Dutch. Do you speak Dutch? Help us to translate
9+
it by sending us pull requests!
10+
{{% /notice %}}
11+
12+
13+
Generally speaking, there’s two reasons why you might want to use Grid.
14+
15+
* To run your tests against multiple browsers, multiple versions of browser,
16+
and browsers running on different operating systems.
17+
* To reduce the time it takes for the test suite to complete a test pass.
18+
19+
Grid is used to speed up the execution of a test pass by using
20+
multiple machines to run tests in parallel. For example, if you have a suite of
21+
100 tests, but you set up Grid to support 4 different machines (VMs or
22+
separate physical machines) to run those tests, your test suite will complete
23+
in (roughly) one-fourth the time as it would if you ran your tests sequentially
24+
on a single machine. For large test suites, and long-running test suite such as
25+
those performing large amounts of data-validation, this can be a significant
26+
time-saver. Some test suites can take hours to run. Another reason to boost the
27+
time spent running the suite is to shorten the turnaround time for test results
28+
after developers check-in code for the AUT. Increasingly software teams
29+
practicing Agile software development want test feedback as immediately as
30+
possible as opposed to wait overnight for an overnight test pass.
31+
32+
Grid is also used to support running tests against multiple runtime
33+
environments, specifically, against different browsers at the same time. For
34+
example, a ‘grid’ of virtual machines can be setup with each supporting a
35+
different browser that the application to be tested must support. So, machine 1
36+
has Internet Explorer 8, machine 2, Internet Explorer 9, machine 3 the latest
37+
Chrome, and machine 4 the latest Firefox. When the test suite is run,
38+
Selenium-Grid receives each test-browser combination and assigns each test to
39+
run against its required browser.
40+
41+
In addition, one can have a grid of all the same browser, type and version. For
42+
instance, one could have a grid of 4 machines each running 3 instances of
43+
Firefox 70, allowing for a ‘server-farm’ (in a sense) of available Firefox
44+
instances. When the suite runs, each test is passed to Grid which
45+
assigns the test to the next available Firefox instance. In this manner one
46+
gets test pass where conceivably 12 tests are all running at the same time in
47+
parallel, significantly reducing the time required to complete a test pass.
48+
49+
Grid is very flexible. These two examples can be combined to allow
50+
multiple instances of each browser type and version. A configuration such as
51+
this would provide both, parallel execution for fast test pass completion and
52+
support for multiple browser types and versions simultaneously.
Lines changed: 52 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,52 @@
1+
---
2+
title: "When to use Grid"
3+
weight: 4
4+
---
5+
6+
{{% notice info %}}
7+
<i class="fas fa-language"></i> Page being translated from
8+
English to Chinese. Do you speak Chinese? Help us to translate
9+
it by sending us pull requests!
10+
{{% /notice %}}
11+
12+
13+
Generally speaking, there’s two reasons why you might want to use Grid.
14+
15+
* To run your tests against multiple browsers, multiple versions of browser,
16+
and browsers running on different operating systems.
17+
* To reduce the time it takes for the test suite to complete a test pass.
18+
19+
Grid is used to speed up the execution of a test pass by using
20+
multiple machines to run tests in parallel. For example, if you have a suite of
21+
100 tests, but you set up Grid to support 4 different machines (VMs or
22+
separate physical machines) to run those tests, your test suite will complete
23+
in (roughly) one-fourth the time as it would if you ran your tests sequentially
24+
on a single machine. For large test suites, and long-running test suite such as
25+
those performing large amounts of data-validation, this can be a significant
26+
time-saver. Some test suites can take hours to run. Another reason to boost the
27+
time spent running the suite is to shorten the turnaround time for test results
28+
after developers check-in code for the AUT. Increasingly software teams
29+
practicing Agile software development want test feedback as immediately as
30+
possible as opposed to wait overnight for an overnight test pass.
31+
32+
Grid is also used to support running tests against multiple runtime
33+
environments, specifically, against different browsers at the same time. For
34+
example, a ‘grid’ of virtual machines can be setup with each supporting a
35+
different browser that the application to be tested must support. So, machine 1
36+
has Internet Explorer 8, machine 2, Internet Explorer 9, machine 3 the latest
37+
Chrome, and machine 4 the latest Firefox. When the test suite is run,
38+
Selenium-Grid receives each test-browser combination and assigns each test to
39+
run against its required browser.
40+
41+
In addition, one can have a grid of all the same browser, type and version. For
42+
instance, one could have a grid of 4 machines each running 3 instances of
43+
Firefox 70, allowing for a ‘server-farm’ (in a sense) of available Firefox
44+
instances. When the suite runs, each test is passed to Grid which
45+
assigns the test to the next available Firefox instance. In this manner one
46+
gets test pass where conceivably 12 tests are all running at the same time in
47+
parallel, significantly reducing the time required to complete a test pass.
48+
49+
Grid is very flexible. These two examples can be combined to allow
50+
multiple instances of each browser type and version. A configuration such as
51+
this would provide both, parallel execution for fast test pass completion and
52+
support for multiple browser types and versions simultaneously.

0 commit comments

Comments
 (0)