CalvinKirs commented on a change in pull request #438:
URL:
https://github.com/apache/dolphinscheduler-website/pull/438#discussion_r713892734
##########
File path: blog/zh-cn/ut-template.md
##########
@@ -0,0 +1,402 @@
+# DolphinScheduler 单元测试模版
+
+## 1. 单元测试原则
+
+1. **3A 原则**
+
+ 3A
原则简单易懂，它为套件中的所有测试提供了统一的结构，这种统一的结构是其最大的优势之一：一旦习惯了这种模式，就可以更轻松地阅读和理解测试，这反过来又降低了整个测试套件的维护成本。
+
+ - Arrange：初始化测试数据。
+ - Act：调用被测方法，传入依赖参数并获取返回值。
+ - Assert：断言，对返回值做出断言。
+
+ 示例：
+
+ ```java
+ public class Calculator {
+ public long sum(long a, long b) {
+ return a + b;
+ }
+ }
+ ```
+
+ ```java
+ public class CalculatorTest {
+ @Test
+ public void sum() {
+ // Arrange
+ long a = 1L, b = 2L;
+ Calculator calculator = new Calculator();
+ // Act
+ long actual = calculator.sum(a, b);
+ // Assert
+ long expected = 3L;
+ assertEquals(expected, actual);
+ }
+ }
+ ```
+
+2. **AIR 原则**
+ - Automatic：测试过程应当是完全自动的、非交互的。
+ - Independent：为了保证单元测试稳定可靠且便于维护，单元测试用例之间不允许互相调用，也不能依赖执行的先后次序。
+ - Repeatable：单元测试是可以重复执行的，不能受到外界环境的影响。
+
+除此以外，还应遵循以下原则：
+
+1. **隔离性与单一性**
+
+一个测试类应该只对应于一个被测试类，并且对被测试类行为的测试环境应该是隔离的。
+
+一个测试用例应该精确到方法级别，并应该能够单独执行该测试用例，同时关注点也始终在该方法上。
+
+如果方法过于复杂，开发阶段就应该将其再次进行拆分，对于测试用例来讲，最佳做法是一个用例只关注一个分支（判断）。当对其进行修改后，也仅仅影响一个测试用例的成功与否。这会极大方便我们在开发阶段验证问题和解决问题，但与此同时，也对我们覆盖率提出了极大的挑战。
+
+2. **可重复性**
+
+在任何环境、任何时间，多次执行后的结果一致，且可以重复执行。
+
+3. **轻量型**
+
+测试应当是秒级甚至是毫秒级的，不应占用过多时间。
+
+> 由于 Spring Boot 启动花费时间较长，因此当待测试对象不依赖 Spring Bean 或 Spring 容器时，应当避免使用 Spring
Test 进行单元测试，可以通过直接创建目标类对象的方式实现。
+
+4. **可测性**
+
+可以通过 mock 框架模拟构造方法、静态方法、final 方法等。
+
Review comment:
This statement is not correct. please refer
https://dolphinscheduler.apache.org/zh-cn/community/development/unit-test.html
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
