From 87749d82c7dfc0f03685c7af169fd1e9aea8aeed Mon Sep 17 00:00:00 2001 From: Alex Zhukovich Date: Sun, 13 Dec 2020 21:15:15 +0100 Subject: [PATCH] Fixed link to IdlingResources in "Never use sleep in test code" article --- _articles/2020-09-20-never-use-sleep-in-test-code.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_articles/2020-09-20-never-use-sleep-in-test-code.md b/_articles/2020-09-20-never-use-sleep-in-test-code.md index d70b605..0cf4a9f 100644 --- a/_articles/2020-09-20-never-use-sleep-in-test-code.md +++ b/_articles/2020-09-20-never-use-sleep-in-test-code.md @@ -20,7 +20,7 @@ Let's take a look at alternatives that we can use for replacing `sleep` methods. * integrating test framework to application ## Checking condition multiple times until timeout is over -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)). 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. +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. ## Integrating test framework to application 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.