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

vinoth pushed a commit to branch asf-site
in repository https://gitbox.apache.org/repos/asf/hudi.git


The following commit(s) were added to refs/heads/asf-site by this push:
     new f550175  [HUDI-1034][DOCS] Add code guidelines for writing tests 
(#2169)
f550175 is described below

commit f550175e6abd56552a1b3dce96ea22a0ae1b7d08
Author: Raymond Xu <2701446+xushi...@users.noreply.github.com>
AuthorDate: Sun Oct 11 17:54:50 2020 -0700

    [HUDI-1034][DOCS] Add code guidelines for writing tests (#2169)
---
 docs/_pages/contributing.md | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/docs/_pages/contributing.md b/docs/_pages/contributing.md
index bb30a84..7db925a 100644
--- a/docs/_pages/contributing.md
+++ b/docs/_pages/contributing.md
@@ -184,6 +184,24 @@ of how we want to evolve our code in the future.
    - Any changes to methods annotated with `PublicAPIMethod` or classes 
annotated with `PublicAPIClass` require upfront discussion and potentially an 
RFC.
    - Any non-backwards compatible changes similarly need upfront discussion 
and the functionality needs to implement an upgrade-downgrade path.
 
+#### Tests
+
+- **Categories**
+    - unit - testing basic functionality at the class level, potentially using 
mocks. Expected to finish quicker
+    - functional - brings up the services needed and runs test without mocking
+    - integration - runs subset of functional tests, on a full fledged 
enviroment with dockerized services
+- **Prepare Test Data**
+    - Many unit and functional test cases require a Hudi dataset to be 
prepared beforehand. `HoodieTestTable` and `HoodieWriteableTestTable` are 
dedicated test utility classes for this purpose. Use them whenever appropriate, 
and add new APIs to them when needed.
+    - When add new APIs in the test utility classes, overload APIs with 
variety of arguments to do more heavy-liftings for callers.
+    - In most scenarios, you won't need to use `FileCreateUtils` directly.
+    - If test cases require interaction with actual `HoodieRecord`s, use 
`HoodieWriteableTestTable` (and `HoodieTestDataGenerator` probably). Otherwise, 
`HoodieTestTable` that manipulates empty files shall serve the purpose.
+- **Strive for Readability**
+    - Avoid writing flow controls for different assertion cases. Split to a 
new test case when appropriate.
+    - Use plain for-loop to avoid try-catch in lambda block. Declare 
exceptions is okay.
+    - Use static import for constants and static helper methods to avoid 
lengthy code.
+    - Avoid reusing local variable names. Create new variables generously.
+    - Keep helper methods local to the test class until it becomes obviously 
generic and re-useable. When that happens, move the helper method to the right 
utility class. For example, `Assertions` contains common assert helpers, and 
`SchemaTestUtil` is for schema related helpers.
+    - Avoid putting new helpers in `HoodieTestUtils` and 
`HoodieClientTestUtils`, which are named too generic. Eventually, all test 
helpers shall be categorized properly.  
 
 ### Reviewing Code/RFCs
 

Reply via email to