Merge pull request #4 from ui-testing-academy/main

Sync fork

Author: AlexZhukovich

_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.