You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: _articles/2020-09-20-never-use-sleep-in-test-code.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -20,7 +20,7 @@ Let's take a look at alternatives that we can use for replacing `sleep` methods.
20
20
* integrating test framework to application
21
21
22
22
## Checking condition multiple times until timeout is over
23
-
A typical implementation of the wait method appears in different frameworks, like UiAutomator (`wait`), Appium (`waitForElement`), Espresso (custom ). This approach's main idea is to check the condition more than once until timeout is over. Let's imagine that we have a `wait` function with a timeout for 3 seconds, and we will check the condition every second. It means that this function can be done after 1, 2, or 3 seconds, and we can save a lot of time if this function takes more than 1 second for many test cases.
23
+
A typical implementation of the wait method appears in different frameworks, like UiAutomator (`wait`), Appium (`waitForElement`), Espresso (custom [Idling Resource](https://developer.android.com/training/testing/espresso/idling-resource){:target="_blank"}). This approach's main idea is to check the condition more than once until timeout is over. Let's imagine that we have a `wait` function with a timeout for 3 seconds, and we will check the condition every second. It means that this function can be done after 1, 2, or 3 seconds, and we can save a lot of time if this function takes more than 1 second for many test cases.
24
24
25
25
## Integrating test framework to application
26
26
Sometimes we can face a different approach, when we have to integrate a test framework inside the application. In this case, when the long-running operation starts, we tell the testing framework that the test case should wait. When the process is finished, we provide information to the framework that the test case can be continued — however, the main problem of this approach that our application is connected with a specific test framework. It can complicate migration to a new framework in the future, and you should always synchronize application code with test code.
0 commit comments