ZeroCode簡介
1.概述
在本文中,我們將介紹ZeroCode自動化測試框架。我們將通過一個REST API測試示例來學習基礎知識。
2.方法
ZeroCode框架採用以下方法:
- 多方面的測試支持
- 聲明式測試
讓我們一起討論它們。
2.1。多方面的測試支持
該框架旨在支持對我們應用程序的多個方面進行自動化測試。除其他外,它使我們能夠測試:
- REST
- SOAP
- 安全
- 壓力测试
- 數據庫
- Apache Kafka
- GraphQL
- Open API規範
測試是通過框架的DSL完成的,我們將在稍後進行討論。
2.2。聲明式
ZeroCode使用一種聲明式的測試樣式,這意味著我們不必編寫實際的測試代碼。我們在JSON / YAML文件中聲明場景,然後框架會將它們“翻譯”為幕後測試代碼。這有助於我們將精力集中在要測試的內容上,而不是如何進行測試。
3.依賴項
pom.xml
文件中添加Maven依賴項:
<dependency>
<groupId>org.jsmart</groupId>
<artifactId>zerocode-tdd</artifactId>
<version>1.3.27</version>
<scope>test</scope>
</dependency>
最新版本在Maven Central上可用。我們也可以使用Gradle。如果使用的是IntelliJ,則可以從Jetbrains Marketplace下載ZeroCode插件。
4. REST API測試
如上所述,ZeroCode可以支持測試應用程序的多個部分。在本文中,我們將重點介紹REST API測試。因此,我們將創建一個小型的Spring Boot Web應用程序並公開一個端點:
@PostMapping
public ResponseEntity create(@RequestBody User user) {
if (!StringUtils.hasText(user.getFirstName())) {
return new ResponseEntity("firstName can't be empty!", HttpStatus.BAD_REQUEST);
}
if (!StringUtils.hasText(user.getLastName())) {
return new ResponseEntity("lastName can't be empty!", HttpStatus.BAD_REQUEST);
}
user.setId(UUID.randomUUID().toString());
users.add(user);
return new ResponseEntity(user, HttpStatus.CREATED);
}
讓我們看看在控制器中引用User
public class User {
private String id;
private String firstName;
private String lastName;
// standard getters and setters
}
創建用戶時,我們設置唯一的ID,然後將整個User
對象返回給客戶端。端點在/api/users
路徑中可訪問。我們將把用戶保存在內存中,以使事情變得簡單。
5.編寫方案
該方案在ZeroCode中起著核心作用。它由一個或多個步驟組成,這是我們要測試的實際內容。讓我們用一個步驟編寫一個場景,以測試用戶創建的成功路徑:
{
"scenarioName": "test user creation endpoint",
"steps": [
{
"name": "test_successful_creation",
"url": "/api/users",
"method": "POST",
"request": {
"body": {
"firstName": "John",
"lastName": "Doe"
}
},
"verify": {
"status": 201,
"body": {
"id": "$NOT.NULL",
"firstName": "John",
"lastName": "Doe"
}
}
}
]
}
讓我們解釋一下每個屬性代表什麼:
-
scenarioName
名稱–這是方案的名稱;我們可以使用我們想要的任何名稱 steps
– JSON對像數組,我們在其中描述要測試的內容-
name
-我們為步驟指定的名稱 -
url
–端點的相對URL;我們也可以輸入一個絕對URL,但是通常這不是一個好主意 -
method
– HTTP方法 request
– HTTP請求-
body
– HTTP請求正文
-
verify
–在這裡,我們驗證/確認服務器返回的響應-
status
– HTTP響應狀態代碼 -
body
(在verify屬性內)– HTTP響應正文
-
-
在此步驟中,我們檢查用戶創建是否成功。我們檢查服務器返回firstName
和lastName
另外,我們使用ZeroCode的斷言令牌來驗證id是否不為null
通常,在方案中我們要完成多個步驟。讓我們在場景的steps
數組中添加另一個步驟:
{
"name": "test_firstname_validation",
"url": "/api/users",
"method": "POST",
"request": {
"body": {
"firstName": "",
"lastName": "Doe"
}
},
"verify": {
"status": 400,
"rawBody": "firstName can't be empty!"
}
}
在此步驟中,我們提供了一個空的名字,這將導致錯誤的請求。在這裡,響應主體將不是JSON格式,因此我們使用rawbody
屬性將其稱為純字符串。
ZeroCode無法直接運行該場景-為此,我們需要一個相應的測試用例。
6.編寫測試用例
為了執行我們的場景,讓我們編寫一個相應的測試用例:
@RunWith(ZeroCodeUnitRunner.class)
@TargetEnv("rest_api.properties")
public class UserEndpointIT {
@Test
@Scenario("rest/user_create_test.json")
public void test_user_creation_endpoint() {
}
}
在這裡,我們聲明一個方法,並使用@Test
批註將其標記為測試。我們可以將JUnit 5與ZeroCode一起使用,僅用於負載測試。
@Scenario
註釋指定了腳本的位置,該註釋來自ZeroCode框架。方法主體為空。正如我們所說,我們沒有編寫實際的測試代碼。我們的場景中描述了我們要測試的內容。我們只是在測試案例方法中引用該場景。我們的UserEndpointIT
類具有兩個註釋:
-
@RunWith
–在這裡,我們指定哪個ZeroCode類負責運行我們的方案 -
@TargetEnv
–這指向在我們的方案運行時將使用的屬性文件
當我們在url
屬性時,我們指定了相對路徑。顯然,ZeroCode框架需要一個絕對路徑,因此我們創建了一個rest_api.properties
文件,其中包含一些用於定義測試運行方式的屬性:
-
web.application.endpoint.host
– REST API的主機;在我們的例子中,它是http://localhost
-
web.application.endpoint.port
–公開我們的REST API的應用程序服務器的端口;在我們的例子中是8080 -
web.application.endpoint.context
– API的上下文;在我們的情況下,它是空的
我們在屬性文件中聲明的屬性取決於我們正在執行的測試類型。例如,如果我們要測試Kafka生產者/消費者,我們將具有不同的屬性。
7.執行測試
我們已經創建了一個場景,屬性文件和測試用例。現在,我們準備運行測試。由於ZeroCode是一個集成測試工具,因此我們可以利用Maven的failsafe
插件:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-failsafe-plugin</artifactId>
<version>3.0.0-M5</version>
<dependencies>
<dependency>
<groupId>org.apache.maven.surefire</groupId>
<artifactId>surefire-junit47</artifactId>
<version>3.0.0-M5</version>
</dependency>
</dependencies>
<executions>
<execution>
<goals>
<goal>integration-test</goal>
<goal>verify</goal>
</goals>
</execution>
</executions>
</plugin>
要運行測試,我們可以使用以下命令:
mvn verify -Dskip.it=false
ZeroCode創建了多種類型的日誌,我們可以在${project.basedir}/target
文件夾中籤出。
8.結論
在本文中,我們研究了ZeroCode自動化測試框架。我們以REST API測試為例展示了該框架如何工作。我們還了解到ZeroCode DSL消除了編寫實際測試代碼的需要。