Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly
Sign up
Appearance settings

Commit 357f13b

Browse files
updates based on feedback and removing unnecessary explanations
1 parent f9174d3 commit 357f13b

File tree

4 files changed

+135
-323
lines changed

4 files changed

+135
-323
lines changed

‎website_and_docs/content/documentation/webdriver/waits.en.md‎

Lines changed: 33 additions & 80 deletions
Original file line numberDiff line numberDiff line change
@@ -7,89 +7,54 @@ aliases: ["/documentation/en/webdriver/waits/"]
77

88
Perhaps the most common challenge for browser automation is ensuring
99
that the web application is in a state to execute a particular
10-
Selenium command as desired. the processes often end up in
10+
Selenium command as desired. The processes often end up in
1111
a _race condition_ where sometimes the browser gets into the right
1212
state first (things work as intended) and sometimes the Selenium code
13-
executes first (things do not work as intended). This is the
14-
primary cause of _flaky tests_.
13+
executes first (things do not work as intended). This is one of the
14+
primary causes of _flaky tests_.
1515

1616
All navigation commands wait for a specific `readyState` value
1717
based on the [page load strategy]({{< ref "drivers/options#pageloadstrategy" >}}) (the
18-
default is `"complete"`) before the driver returns control to the code.
18+
default value to wait for is `"complete"`) before the driver returns control to the code.
1919
The `readyState` only concerns itself with loading assets defined in the HTML,
2020
but loaded JavaScript assets often result in changes to the site,
21-
and elements you need to interact with may not yet be on the page
21+
and elements that need to be interacted with may not yet be on the page
2222
when the code is ready to execute the next Selenium command.
2323

2424
Similarly, in a lot of single page applications, elements get dynamically
25-
added to a page or change visibility based on a click. For example, the box
26-
element takes a second to show up after clicking on the "adder" button, so
27-
even trying to locate that button will error without some form of synchronization:
25+
added to a page or change visibility based on a click.
26+
An element must be both present and
27+
[displayed](({{< ref "elements/information/#is-displayed" >}})) on the page
28+
in order for Selenium to interact with it.
2829

29-
{{< tabpane text=true langEqualsHeader=true >}}
30-
{{< tab header="Java" >}}
31-
{{< gh-codeblock path="examples/java/src/test/java/dev/selenium/waits/WaitsTest.java#L23-L28" >}}
32-
{{< /tab >}}
33-
{{< tab header="Python" >}}
34-
{{< gh-codeblock path="examples/python/tests/waits/test_waits.py#L9-L13" >}}
35-
{{< /tab >}}
36-
{{< tab header="CSharp" >}}
37-
{{< gh-codeblock path="examples/dotnet/SeleniumDocs/Waits/WaitsTest.cs#L15-L20" >}}
38-
{{< /tab >}}
39-
{{< tab header="Ruby" >}}
40-
{{< gh-codeblock path="examples/ruby/spec/waits/waits_spec.rb#L9-L14" >}}
41-
{{< /tab >}}
42-
{{< tab header="JavaScript" >}}
43-
{{< badge-code >}}
44-
{{< /tab >}}
45-
{{< tab header="Kotlin" >}}
46-
{{< badge-code >}}
47-
{{< /tab >}}
48-
{{< /tabpane >}}
30+
Take this page for example: https://www.selenium.dev/selenium/web/dynamic.html
31+
When the "Add a box!" button is clicked, a "div" element that does not exist is created.
32+
When the "Reveal a new input" button is clicked, a hidden text field element is displayed.
33+
In both cases the transition takes a couple seconds.
34+
If the Selenium code is to click one of these buttons and interact with the resulting element,
35+
it will do so before that element is ready and fail.
4936

50-
There are several synchronization strategies that can be used to properly wait for
51-
the application to be in the state you need it to be for the next Selenium command.
37+
The first solution many people turn to is adding a sleep statement to
38+
pause the code execution for a set period of time.
39+
Because the code can't know exactly how long it needs to wait, this
40+
can fail when it doesn't sleep long enough. Alternately, if the value is set too high
41+
and a sleep statement is added in every place it is needed, the duration of
42+
the session can become prohibitive.
5243

53-
## Hard-coded sleeps
44+
Selenium provides two different mechanisms for synchronization that are better.
5445

55-
This causes the code to stop executing for a set period of time.
56-
Because your code can't know exactly how long you need to wait, this
57-
will either fail when it doesn't sleep long enough, or will cause
58-
your sessions to take much longer than they need to. That said, putting in a sleep command is one way to keep
59-
the above code from failing:
60-
61-
{{< tabpane text=true langEqualsHeader=true >}}
62-
{{< tab header="Java" >}}
63-
{{< gh-codeblock path="examples/java/src/test/java/dev/selenium/waits/WaitsTest.java#L34-L38" >}}
64-
{{< /tab >}}
65-
{{< tab header="Python" >}}
66-
{{< gh-codeblock path="examples/python/tests/waits/test_waits.py#L18-L21" >}}
67-
{{< /tab >}}
68-
{{< tab header="CSharp" >}}
69-
{{< gh-codeblock path="examples/dotnet/SeleniumDocs/Waits/WaitsTest.cs#L27-L31" >}}
70-
{{< /tab >}}
71-
{{< tab header="Ruby" >}}
72-
{{< gh-codeblock path="examples/ruby/spec/waits/waits_spec.rb#L19-L22" >}}
73-
{{< /tab >}}
74-
{{< tab header="JavaScript" >}}
75-
{{< badge-code >}}
76-
{{< /tab >}}
77-
{{< tab header="Kotlin" >}}
78-
{{< badge-code >}}
79-
{{< /tab >}}
80-
{{< /tabpane >}}
8146

8247
## Implicit waits
8348
Selenium has a built-in way to automatically wait for elements called an _implicit wait_.
84-
You set an implicit wait either with the [timeouts](({{< ref "drivers/options#timeouts" >}}))
49+
An implicit wait value can be set either with the [timeouts](({{< ref "drivers/options#timeouts" >}}))
8550
capability in the browser options, or with a driver method (as shown below).
8651

8752
This is a global setting that applies to every element location call for the entire session.
8853
The default value is `0`, which means that if the element is not found, it will
8954
immediately return an error. If an implicit wait is set, the driver will wait for the
9055
duration of the provided value before returning the error. Note that as soon as the
91-
element is located, the driver will return the value and your code may continue, so a larger
92-
implicit wait value won't necessarily increase the time of your session.
56+
element is located, the driver will return the element reference and the code will continue executing,
57+
so a larger implicit wait value won't necessarily increase the duration of the session.
9358

9459
*Warning:*
9560
Do not mix implicit and explicit waits.
@@ -123,25 +88,13 @@ Solving our example with an implicit wait looks like this:
12388

12489
## Explicit waits
12590

126-
_Explicit waits_ are loops you add to your code that poll the application
91+
_Explicit waits_ are loops added to the code that poll the application
12792
for a specific condition to evaluate as true before it exits the loop and
128-
continues to the next command in your code. If the condition is not met before a designated timeout value,
129-
the code will give a timeout error.
130-
131-
There are many ways for the application not to be in the desired state,
132-
so explicit waits are a great choice to specify exactly what is desired
133-
in each place they are needed.
134-
For example, an element must be both present in the DOM and
135-
[displayed](({{< ref "elements/information/#is-displayed" >}})) on the page
136-
in order for Selenium to interact with it.
137-
138-
In this example, clicking the
139-
"reveal" button displays an input field that is already present in the DOM.
140-
An explicit wait can be used to ensure the element is interactable before
141-
sending keys to it. An important feature of the Wait class in Selenium is that it will automatically retry
142-
when a _no such element_ error happens, which makes it much easier to write succinct code.
143-
We do not need to handle whether the element is there and we can just focus on whether it
144-
evaluates as displayed:
93+
continues to the next command in the code. If the condition is not met before a designated timeout value,
94+
the code will give a timeout error. Since there are many ways for the application not to be in the desired state,
95+
so explicit waits are a great choice to specify the exact condition to wait for
96+
in each place it is needed.
97+
Another nice feature is that, by default, the Selenium Wait class automatically waits for the designated element to exist.
14598

14699
{{< tabpane text=true langEqualsHeader=true >}}
147100
{{% tab header="Java" %}}
@@ -171,11 +124,11 @@ JavaScript also supports [Expected Conditions](({{< ref "support_features/expect
171124

172125
### Customization
173126

174-
The Wait class can be created with various parameters that will change how the conditions are evaluated.
127+
The Wait class can be instantiated with various parameters that will change how the conditions are evaluated.
175128

176129
This can include:
177130
* Changing how often the code is evaluated (polling interval)
178-
* Specifying which exceptions should be retried
131+
* Specifying which exceptions should be handled automatically
179132
* Changing the total timeout length
180133
* Customizing the timeout message
181134

‎website_and_docs/content/documentation/webdriver/waits.ja.md‎

Lines changed: 34 additions & 81 deletions
Original file line numberDiff line numberDiff line change
@@ -7,89 +7,54 @@ aliases: ["/documentation/ja/webdriver/waits/"]
77

88
Perhaps the most common challenge for browser automation is ensuring
99
that the web application is in a state to execute a particular
10-
Selenium command as desired. the processes often end up in
10+
Selenium command as desired. The processes often end up in
1111
a _race condition_ where sometimes the browser gets into the right
1212
state first (things work as intended) and sometimes the Selenium code
13-
executes first (things do not work as intended). This is the
14-
primary cause of _flaky tests_.
13+
executes first (things do not work as intended). This is one of the
14+
primary causes of _flaky tests_.
1515

1616
All navigation commands wait for a specific `readyState` value
17-
based on the [page load strategy]({{< ref "drivers/options#pageloadstrategy" >}}) (the
18-
default is `"complete"`) before the driver returns control to the code.
17+
based on the [page load strategy]({{< ref "drivers/options#pageloadstrategy" >}}) (the
18+
default value to wait for is `"complete"`) before the driver returns control to the code.
1919
The `readyState` only concerns itself with loading assets defined in the HTML,
2020
but loaded JavaScript assets often result in changes to the site,
21-
and elements you need to interact with may not yet be on the page
21+
and elements that need to be interacted with may not yet be on the page
2222
when the code is ready to execute the next Selenium command.
2323

2424
Similarly, in a lot of single page applications, elements get dynamically
25-
added to a page or change visibility based on a click. For example, the box
26-
element takes a second to show up after clicking on the "adder" button, so
27-
even trying to locate that button will error without some form of synchronization:
25+
added to a page or change visibility based on a click.
26+
An element must be both present and
27+
[displayed](({{< ref "elements/information/#is-displayed" >}})) on the page
28+
in order for Selenium to interact with it.
2829

29-
{{< tabpane text=true langEqualsHeader=true >}}
30-
{{< tab header="Java" >}}
31-
{{< gh-codeblock path="examples/java/src/test/java/dev/selenium/waits/WaitsTest.java#L23-L28" >}}
32-
{{< /tab >}}
33-
{{< tab header="Python" >}}
34-
{{< gh-codeblock path="examples/python/tests/waits/test_waits.py#L9-L13" >}}
35-
{{< /tab >}}
36-
{{< tab header="CSharp" >}}
37-
{{< gh-codeblock path="examples/dotnet/SeleniumDocs/Waits/WaitsTest.cs#L15-L20" >}}
38-
{{< /tab >}}
39-
{{< tab header="Ruby" >}}
40-
{{< gh-codeblock path="examples/ruby/spec/waits/waits_spec.rb#L9-L14" >}}
41-
{{< /tab >}}
42-
{{< tab header="JavaScript" >}}
43-
{{< badge-code >}}
44-
{{< /tab >}}
45-
{{< tab header="Kotlin" >}}
46-
{{< badge-code >}}
47-
{{< /tab >}}
48-
{{< /tabpane >}}
30+
Take this page for example: https://www.selenium.dev/selenium/web/dynamic.html
31+
When the "Add a box!" button is clicked, a "div" element that does not exist is created.
32+
When the "Reveal a new input" button is clicked, a hidden text field element is displayed.
33+
In both cases the transition takes a couple seconds.
34+
If the Selenium code is to click one of these buttons and interact with the resulting element,
35+
it will do so before that element is ready and fail.
4936

50-
There are several synchronization strategies that can be used to properly wait for
51-
the application to be in the state you need it to be for the next Selenium command.
37+
The first solution many people turn to is adding a sleep statement to
38+
pause the code execution for a set period of time.
39+
Because the code can't know exactly how long it needs to wait, this
40+
can fail when it doesn't sleep long enough. Alternately, if the value is set too high
41+
and a sleep statement is added in every place it is needed, the duration of
42+
the session can become prohibitive.
5243

53-
## Hard-coded sleeps
44+
Selenium provides two different mechanisms for synchronization that are better.
5445

55-
This causes the code to stop executing for a set period of time.
56-
Because your code can't know exactly how long you need to wait, this
57-
will either fail when it doesn't sleep long enough, or will cause
58-
your sessions to take much longer than they need to. That said, putting in a sleep command is one way to keep
59-
the above code from failing:
60-
61-
{{< tabpane text=true langEqualsHeader=true >}}
62-
{{< tab header="Java" >}}
63-
{{< gh-codeblock path="examples/java/src/test/java/dev/selenium/waits/WaitsTest.java#L34-L38" >}}
64-
{{< /tab >}}
65-
{{< tab header="Python" >}}
66-
{{< gh-codeblock path="examples/python/tests/waits/test_waits.py#L18-L21" >}}
67-
{{< /tab >}}
68-
{{< tab header="CSharp" >}}
69-
{{< gh-codeblock path="examples/dotnet/SeleniumDocs/Waits/WaitsTest.cs#L27-L31" >}}
70-
{{< /tab >}}
71-
{{< tab header="Ruby" >}}
72-
{{< gh-codeblock path="examples/ruby/spec/waits/waits_spec.rb#L19-L22" >}}
73-
{{< /tab >}}
74-
{{< tab header="JavaScript" >}}
75-
{{< badge-code >}}
76-
{{< /tab >}}
77-
{{< tab header="Kotlin" >}}
78-
{{< badge-code >}}
79-
{{< /tab >}}
80-
{{< /tabpane >}}
8146

8247
## Implicit waits
8348
Selenium has a built-in way to automatically wait for elements called an _implicit wait_.
84-
You set an implicit wait either with the [timeouts](({{< ref "drivers/options#timeouts" >}}))
49+
An implicit wait value can be set either with the [timeouts](({{< ref "drivers/options#timeouts" >}}))
8550
capability in the browser options, or with a driver method (as shown below).
8651

8752
This is a global setting that applies to every element location call for the entire session.
8853
The default value is `0`, which means that if the element is not found, it will
8954
immediately return an error. If an implicit wait is set, the driver will wait for the
9055
duration of the provided value before returning the error. Note that as soon as the
91-
element is located, the driver will return the value and your code may continue, so a larger
92-
implicit wait value won't necessarily increase the time of your session.
56+
element is located, the driver will return the element reference and the code will continue executing,
57+
so a larger implicit wait value won't necessarily increase the duration of the session.
9358

9459
*Warning:*
9560
Do not mix implicit and explicit waits.
@@ -123,25 +88,13 @@ Solving our example with an implicit wait looks like this:
12388

12489
## Explicit waits
12590

126-
_Explicit waits_ are loops you add to your code that poll the application
91+
_Explicit waits_ are loops added to the code that poll the application
12792
for a specific condition to evaluate as true before it exits the loop and
128-
continues to the next command in your code. If the condition is not met before a designated timeout value,
129-
the code will give a timeout error.
130-
131-
There are many ways for the application not to be in the desired state,
132-
so explicit waits are a great choice to specify exactly what is desired
133-
in each place they are needed.
134-
For example, an element must be both present in the DOM and
135-
[displayed](({{< ref "elements/information/#is-displayed" >}})) on the page
136-
in order for Selenium to interact with it.
137-
138-
In this example, clicking the
139-
"reveal" button displays an input field that is already present in the DOM.
140-
An explicit wait can be used to ensure the element is interactable before
141-
sending keys to it. An important feature of the Wait class in Selenium is that it will automatically retry
142-
when a _no such element_ error happens, which makes it much easier to write succinct code.
143-
We do not need to handle whether the element is there and we can just focus on whether it
144-
evaluates as displayed:
93+
continues to the next command in the code. If the condition is not met before a designated timeout value,
94+
the code will give a timeout error. Since there are many ways for the application not to be in the desired state,
95+
so explicit waits are a great choice to specify the exact condition to wait for
96+
in each place it is needed.
97+
Another nice feature is that, by default, the Selenium Wait class automatically waits for the designated element to exist.
14598

14699
{{< tabpane text=true langEqualsHeader=true >}}
147100
{{% tab header="Java" %}}
@@ -171,11 +124,11 @@ JavaScript also supports [Expected Conditions](({{< ref "support_features/expect
171124

172125
### Customization
173126

174-
The Wait class can be created with various parameters that will change how the conditions are evaluated.
127+
The Wait class can be instantiated with various parameters that will change how the conditions are evaluated.
175128

176129
This can include:
177130
* Changing how often the code is evaluated (polling interval)
178-
* Specifying which exceptions should be retried
131+
* Specifying which exceptions should be handled automatically
179132
* Changing the total timeout length
180133
* Customizing the timeout message
181134

0 commit comments

Comments
(0)

AltStyle によって変換されたページ (->オリジナル) /