[incubator-dolphinscheduler-website] branch master updated: unit test guid

[li...@apache.org]

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

lidongdai pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/incubator-dolphinscheduler-website.git


The following commit(s) were added to refs/heads/master by this push:
     new 766ff1f  unit test guid
     new 2680c5f  Merge pull request #40 from khadgarmage/feature-unittest
766ff1f is described below

commit 766ff1f9b72065f5be3261e726e0ae6b2969c2f7
Author: xiaochun.liu <kh...@outlook.com>
AuthorDate: Wed Nov 27 00:15:08 2019 +0800

    unit test guid
---
 docs/en-us/development/contribute.md | 17 ++++++++++++++++-
 docs/zh-cn/development/contribute.md | 18 +++++++++++++++++-
 2 files changed, 33 insertions(+), 2 deletions(-)

diff --git a/docs/en-us/development/contribute.md b/docs/en-us/development/contribute.md
index 8a6fb13..5990722 100755
--- a/docs/en-us/development/contribute.md
+++ b/docs/en-us/development/contribute.md
@@ -1 +1,16 @@
-## todo
+## Unit Test coverage
+Unit test writing reference [link](https://github.com/apache/incubator-dolphinscheduler/blob/dev/escheduler-common/src/test/java/cn/escheduler/common/utils/CollectionUtilsTest.java)
+### 1.The benefits of unit testing 
+  * Unit test code can help everyone to go into details and understand the function of the code.
+  * We can find bugs by test case, and then enhance the robustness of the code.
+  * Test case code is also the demo usage of the core code.
+### 2.Some design principle of unit test case 
+  * Steps, fine-grained and combination conditions should be well designed.
+  * Attention to boundary condition test
+  * Test code should also be designed without writing useless code.
+  * When you find a `method` that is hard to write unit test, if you can be sure the `method` is "smelly code", then  refactor it with the committer.
+  * The mock framework in DolphinScheduler is: [mockito](http://site.mockito.org/). Some tutorials:[mockito tutorial](http://www.baeldung.com/bdd-mockito),[mockito refcard](https://dzone.com/refcardz/mockito)
+  * TDD（optional）：When you start a new issue, you can try to write test case at first 
+### 3.The specified value of the test coverage
+  * In the stage, the test coverage specified value of delta changed codes is ：>=60%. The higher, the better.
+  * We can see the coverage report in this page: https://codecov.io/gh/apache/dolphinscheduler
diff --git a/docs/zh-cn/development/contribute.md b/docs/zh-cn/development/contribute.md
index 5a3c3d8..2d7e03d 100755
--- a/docs/zh-cn/development/contribute.md
+++ b/docs/zh-cn/development/contribute.md
@@ -1 +1,17 @@
-## 未完成
+## Unit Test覆盖率
+Unit Test编写参考[链接](https://github.com/apache/incubator-dolphinscheduler/blob/dev/escheduler-common/src/test/java/cn/escheduler/common/utils/CollectionUtilsTest.java)
+### 1.写单元测试的收益 
+  * 单元测试能帮助每个人深入代码细节，了解代码的功能。
+  * 通过测试用例我们能发现bug，并提交代码的健壮性。
+  * 测试用例同时也是代码的demo用法。
+### 2.单元测试用例的一些设计原则 
+  * 应该精心设计好步骤，颗粒度和组合条件。
+  * 注意边界条件。
+  * 单元测试也应该好好设计，不要写无用的代码。
+  * 当你发现一个`方法`很难写单元测试时，如果可以确认这个`方法`是`臭代码`，那么就和开发者一起重构它。
+  * DolphinScheduler: [mockito](http://site.mockito.org/). 下面是一些开发向导:[mockito tutorial](http://www.baeldung.com/bdd-mockito),[mockito refcard](https://dzone.com/refcardz/mockito)
+  * TDD（可选）：当你开始写一个新的功能时，你可以试着先写测试用例。 
+### 3.测试覆盖率设定值
+  * 在现阶段，Delta更改代码的测试覆盖设定值为：>＝60%，越高越好。
+  * 我们可以在这个页面中看到测试报告: https://codecov.io/gh/apache/dolphinscheduler
+