怎樣編寫測試類測試分支

很難為干凈的代碼找到一個(gè)好的定義，因?yàn)槲覀兠總€(gè)人都有自己的單詞clean的定義。 但是，有一個(gè)似乎是通用的定義：

簡潔的代碼易于閱讀。

這可能會(huì)讓您感到有些驚訝，但我認(rèn)為該定義也適用于測試代碼。 使測試盡可能具有可讀性是我們的最大利益，因?yàn)?#xff1a;

• 如果我們的測試易于閱讀，那么很容易理解我們的代碼是如何工作的。
• 如果我們的測試易于閱讀，那么如果測試失敗（不使用調(diào)試器），很容易發(fā)現(xiàn)問題。

編寫干凈的測試并不難，但是需要大量的實(shí)踐，這就是為什么如此多的開發(fā)人員為此苦苦掙扎的原因。

我也為此感到掙扎，這就是為什么我決定與您分享我的發(fā)現(xiàn)的原因。

這是本教程的第一部分，介紹了如何編寫干凈的測試。 這次，我們將學(xué)習(xí)如何以簡單干凈的方式配置測試用例。

問題

假設(shè)我們必須使用Spring MVC Test框架為Spring MVC控制器編寫“單元測試”。 我們要測試的第一個(gè)控制器稱為TodoController ，但是我們還必須為應(yīng)用程序的其他控制器編寫“單元測試”。

作為開發(fā)人員，我們知道重復(fù)的代碼是一件壞事。 在編寫代碼時(shí)，我們遵循“ 不要重復(fù)自己（DRY）”原則 ，該原則指出：

每條知識(shí)都必須在系統(tǒng)中具有單一，明確，權(quán)威的表示形式。

我懷疑這是開發(fā)人員經(jīng)常在其測試套件中使用繼承的原因之一。 他們將繼承視為重用代碼和配置的廉價(jià)且簡便的方法。 這就是為什么他們將所有通用代碼和配置放在實(shí)際測試類的基類中的原因。

讓我們看看如何使用該方法配置“單元測試”。

首先 ，我們必須創(chuàng)建一個(gè)抽象基類， 該基類可以配置Spring MVC Test框架，并通過實(shí)現(xiàn)setUpTest（MockMvc mockMvc）方法來確保其子類可以提供其他配置。

AbstractControllerTest類的源代碼如下所示：

import org.junit.Before; import org.junit.runner.RunWith; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.test.context.ContextConfiguration; import org.springframework.test.context.junit4.SpringJUnit4ClassRunner; import org.springframework.test.context.web.WebAppConfiguration; import org.springframework.test.web.servlet.MockMvc; import org.springframework.test.web.servlet.setup.MockMvcBuilders; import org.springframework.web.context.WebApplicationContext;@RunWith(SpringJUnit4ClassRunner.class) @ContextConfiguration(classes = {WebUnitTestContext.class}) @WebAppConfiguration public abstract class AbstractControllerTest {private MockMvc mockMvc;@Autowiredprivate WebApplicationContext webAppContext;@Beforepublic void setUp() {mockMvc = MockMvcBuilders.webAppContextSetup(webAppContext).build();setupTest(MockMvc mockMvc)}protected abstract void setUpTest(MockMvc mockMvc); }

其次 ，我們必須實(shí)現(xiàn)實(shí)際的測試類，該類創(chuàng)建所需的模擬和新的控制器對象。 TodoControllerTest類的源代碼如下所示：

import org.mockito.Mockito; import org.springframework.test.web.servlet.MockMvc;public class TodoControllerTest extends AbstractControllerTest {private MockMvc mockMvc;@Autowiredprivate TodoService serviceMock;@Overrideprotected void setUpTest(MockMvc mockMvc) {Mockito.reset(serviceMock);this.mockMvc = mockMvc;}//Add test methods here }

這個(gè)測試類看起來很干凈，但是有一個(gè)主要缺陷：

如果我們想了解測試用例的配置方式，我們必須閱讀TodoControllerTest和AbstractControllerTest類的源代碼。

這似乎是一個(gè)小問題，但這意味著我們必須將注意力從測試用例轉(zhuǎn)移到基類（或多個(gè)類）上。 這需要精神上的上下文切換，并且上下文切換非常昂貴 。

您可能當(dāng)然會(huì)爭辯說，在這種情況下使用繼承的精神代價(jià)很低，因?yàn)榕渲梅浅：唵巍?的確如此，但是要記住，現(xiàn)實(shí)生活中的情況并非總是如此。

上下文切換的實(shí)際成本取決于測試類層次結(jié)構(gòu)的深度和配置的復(fù)雜性。

解決方案

我們可以通過配置測試類中的所有測試用例來提高配置的可讀性。 這意味著我們必須：

• 將所需的注釋（例如@RunWith ）添加到測試類。
• 將設(shè)置和拆卸方法添加到測試類。

如果我們遵循以下規(guī)則修改示例測試類，則其源代碼如下：

import org.junit.Before; import org.junit.runner.RunWith; import org.mockito.Mockito; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.test.context.ContextConfiguration; import org.springframework.test.context.junit4.SpringJUnit4ClassRunner; import org.springframework.test.context.web.WebAppConfiguration; import org.springframework.test.web.servlet.MockMvc; import org.springframework.test.web.servlet.setup.MockMvcBuilders; import org.springframework.web.context.WebApplicationContext;@RunWith(SpringJUnit4ClassRunner.class) @ContextConfiguration(classes = {WebUnitTestContext.class}) @WebAppConfiguration public class TodoControllerTest {private MockMvc mockMvc;@Autowiredprivate TodoService serviceMock;@Autowiredprivate WebApplicationContext webAppContext;@Beforepublic void setUp() {Mockito.reset(serviceMock);mockMvc = MockMvcBuilders.webAppContextSetup(webAppContext).build();}//Add test methods here }

在我看來，我們的測試用例的新配置看起來比舊的配置簡單且干凈得多，舊的配置分為TodoControllerTest和AbstractControllerTest類。

不幸的是，沒有什么是免費(fèi)的。

這是一個(gè)權(quán)衡

每個(gè)軟件設(shè)計(jì)決策都需要權(quán)衡利弊。 這不是該規(guī)則的例外 。

在測試類中配置我們的測試用例具有以下好處：

我們無需閱讀測試類的所有超類就可以了解測試用例的配置。 這樣可以節(jié)省大量時(shí)間，因?yàn)槲覀儾槐貙⒆⒁饬囊惶谜n轉(zhuǎn)移到另一堂課。 換句話說， 我們不必付出上下文切換的代價(jià) 。

當(dāng)測試失敗時(shí)，可以節(jié)省時(shí)間。 如果為了避免重復(fù)的代碼或配置而使用繼承，則很可能我們的基類將包含與某些但不是全部測試用例相關(guān)的組件。 換句話說，我們將弄清楚哪些組件與失敗的測試用例相關(guān)，這可能不是一件容易的事。 在測試類中配置測試用例時(shí)， 我們知道每個(gè)組件都與失敗的測試用例有關(guān) 。

另一方面，這種方法的缺點(diǎn)是：

我們必須編寫重復(fù)的代碼。 這比將所需的配置放到一個(gè)或多個(gè)基類上花費(fèi)的時(shí)間更長。

如果任何使用的庫以迫使我們修改測試配置的方式進(jìn)行更改，則我們必須對每個(gè)測試類進(jìn)行必要的更改。 這顯然比僅對基類（或多個(gè)基類）進(jìn)行這些操作要慢得多。

如果我們唯一的目標(biāo)是盡可能快地編寫測試，那么很明顯，我們應(yīng)該消除重復(fù)的代碼和配置。

但是，這不是我唯一的目標(biāo)。

我認(rèn)為這種方法的優(yōu)點(diǎn)勝于缺點(diǎn)的原因有兩個(gè)：

繼承不是重用代碼或配置的正確工具 。

如果測試用例失敗，我們必須盡快找到并解決問題，并且干凈的配置將幫助我們實(shí)現(xiàn)該目標(biāo)。

我在這件事上的立場是明確的。 但是，仍然存在一個(gè)非常重要的問題：

您會(huì)做出其他折衷嗎？

翻譯自: https://www.javacodegeeks.com/2014/05/writing-clean-tests-it-starts-from-the-configuration.html

怎樣編寫測試類測試分支

總結(jié)

以上是生活随笔為你收集整理的怎样编写测试类测试分支_编写干净的测试–从配置开始的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。