[flink-web] branch asf-site updated: [hotfix] Update coding guidelines for JUnit timeouts

[dw...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

dwysakowicz pushed a commit to branch asf-site
in repository https://gitbox.apache.org/repos/asf/flink-web.git


The following commit(s) were added to refs/heads/asf-site by this push:
     new a25815d  [hotfix] Update coding guidelines for JUnit timeouts
a25815d is described below

commit a25815d154f1acd70ec4ad5c265814ea653116d7
Author: Dawid Wysakowicz <dw...@apache.org>
AuthorDate: Tue May 4 17:58:47 2021 +0200

    [hotfix] Update coding guidelines for JUnit timeouts
---
 contributing/code-style-and-quality-common.md    | 13 ++++++++++++-
 contributing/code-style-and-quality-common.zh.md | 11 +++++++++++
 2 files changed, 23 insertions(+), 1 deletion(-)

diff --git a/contributing/code-style-and-quality-common.md b/contributing/code-style-and-quality-common.md
index 5a52b85..59d3e84 100644
--- a/contributing/code-style-and-quality-common.md
+++ b/contributing/code-style-and-quality-common.md
@@ -232,7 +232,18 @@ then the S3 access should be factored out into an interface and test should repl
     * More details: [https://docs.google.com/presentation/d/1fZlTjOJscwmzYadPGl23aui6zopl94Mn5smG-rB0qT8](https://docs.google.com/presentation/d/1fZlTjOJscwmzYadPGl23aui6zopl94Mn5smG-rB0qT8)
 * Instead, create reusable test implementations and utilities
     * That way, when some class changes, we only have to update a few test utils or mocks
-
+  
+**Avoid timeouts in JUnit tests**
+
+Generally speaking, we should avoid setting local timeouts in JUnit tests but rather depend on the
+global timeout in Azure. The global timeout benefits from taking thread dumps just before timing out
+the build, easing debugging.
+
+At the same time, any timeout value that you manually set is arbitrary. If it's set too low, you get
+test instabilities. What too low means depends on numerous factors, such as hardware and current
+utilization (especially I/O). Moreover, a local timeout is more maintenance-intensive. It's one more
+knob where you can tweak a build. If you change the test a bit, you also need to double-check the
+timeout. Hence, there have been quite a few commits that just increase timeouts.
 
 ### Performance Awareness
 
diff --git a/contributing/code-style-and-quality-common.zh.md b/contributing/code-style-and-quality-common.zh.md
index 365c215..820de78 100644
--- a/contributing/code-style-and-quality-common.zh.md
+++ b/contributing/code-style-and-quality-common.zh.md
@@ -233,6 +233,17 @@ then the S3 access should be factored out into an interface and test should repl
 * Instead, create reusable test implementations and utilities
     * That way, when some class changes, we only have to update a few test utils or mocks
 
+**Avoid timeouts in JUnit tests**
+
+Generally speaking, we should avoid setting local timeouts in JUnit tests but rather depend on the
+global timeout in Azure. The global timeout benefits from taking thread dumps just before timing out
+the build, easing debugging.
+
+At the same time, any timeout value that you manually set is arbitrary. If it's set too low, you get
+test instabilities. What too low means depends on numerous factors, such as hardware and current
+utilization (especially I/O). Moreover, a local timeout is more maintenance-intensive. It's one more
+knob where you can tweak a build. If you change the test a bit, you also need to double-check the
+timeout. Hence, there have been quite a few commits that just increase timeouts.
 
 ### Performance Awareness