過去，很多人問我是否測試吸氣劑和吸氣劑（屬性，屬性等）。 他們還問我是否測試我的建筑商。 在我看來，答案取決于情況。

當(dāng)使用遺留代碼時(shí)，我不會(huì)費(fèi)心去測試數(shù)據(jù)結(jié)構(gòu)，這意味著對象只帶有g(shù)etter和setter，映射，列表等。原因之一是我從不模擬它們。 在測試使用它們的類時(shí)，我照原樣使用它們。 對于構(gòu)建器，當(dāng)它們僅由測試類使用時(shí)，我也不對它們進(jìn)行單元測試，因?yàn)樗鼈冊谠S多其他測試中均被用作“幫助者”。 如果它們有錯(cuò)誤，則測試將失敗。 總而言之，如果這些數(shù)據(jù)結(jié)構(gòu)和構(gòu)建器已經(jīng)存在，我不會(huì)為它們進(jìn)行改裝測試。

但是，現(xiàn)在讓我們談?wù)勥M(jìn)行TDD并假設(shè)您需要一個(gè)帶有g(shù)etter和setter的新對象。 在這種情況下，是的，我將為吸氣劑和吸氣劑編寫測試，因?yàn)槲倚枰染帉憸y試來證明它們的存在。
為了擁有豐富的領(lǐng)域模型，我通常傾向于將業(yè)務(wù)邏輯與數(shù)據(jù)相關(guān)聯(lián)，并擁有更豐富的領(lǐng)域模型。 讓我們看下面的例子。

在現(xiàn)實(shí)生活中，我會(huì)一次編寫測試，使它們通過并重構(gòu)。 在這篇文章中，為清晰起見，我僅向您提供完整的課程。 首先讓我們編寫測試：

package org.craftedsw.testingbuilders;import static org.hamcrest.Matchers.is;import static org.junit.Assert.assertThat;import static org.mockito.Matchers.anyString;import static org.mockito.Mockito.verify;import static org.mockito.Mockito.when;import org.junit.Before;import org.junit.Test;import org.junit.runner.RunWith;import org.mockito.Mock;import org.mockito.runners.MockitoJUnitRunner;@RunWith(MockitoJUnitRunner.class)public class TradeTest {private static final String INBOUND_XML_MESSAGE = '<message >';private static final boolean REPORTABILITY_RESULT = true;private Trade trade;@Mock private ReportabilityDecision reportabilityDecision;@Beforepublic void initialise() {trade = new Trade();when(reportabilityDecision.isReportable(anyString())).thenReturn(REPORTABILITY_RESULT);}@Test public voidshould_contain_the_inbound_xml_message() {trade.setInboundMessage(INBOUND_XML_MESSAGE);assertThat(trade.getInboundMessage(), is(INBOUND_XML_MESSAGE));}@Test public voidshould_tell_if_it_is_reportable() {trade.setInboundMessage(INBOUND_XML_MESSAGE);trade.setReportabilityDecision(reportabilityDecision);boolean reportable = trade.isReportable();verify(reportabilityDecision).isReportable(INBOUND_XML_MESSAGE);assertThat(reportable, is(REPORTABILITY_RESULT));}}

現(xiàn)在執(zhí)行：

package org.craftedsw.testingbuilders;public class Trade {private String inboundMessage;private ReportabilityDecision reportabilityDecision;public String getInboundMessage() {return this.inboundMessage;}public void setInboundMessage(String inboundXmlMessage) {this.inboundMessage = inboundXmlMessage;}public boolean isReportable() {return reportabilityDecision.isReportable(inboundMessage);}public void setReportabilityDecision(ReportabilityDecision reportabilityDecision) {this.reportabilityDecision = reportabilityDecision;}}

這種情況很有趣，因?yàn)門rade對象具有一個(gè)名為inboundMessage的屬性，具有相應(yīng)的getter和setter，并且在其isReportable業(yè)務(wù)方法中還使用了一個(gè)協(xié)作者（reportabilityDecision，通過setter注入）。

我多次看到的“測試” setReportabilityDecision方法的常用方法是引入getReportabilityDecision方法，該方法返回reportabilityDecision（協(xié)作者）對象。

這絕對是錯(cuò)誤的方法。 我們的目標(biāo)應(yīng)該是測試協(xié)作器的使用方式，這意味著是否使用正確的參數(shù)調(diào)用了協(xié)作器，以及是否使用了返回的任何內(nèi)容（如果返回了任何內(nèi)容）。 在這種情況下引入吸氣劑是沒有意義的，因?yàn)樗荒鼙ＷC在通過設(shè)置器注入了協(xié)作者之后，對象將按照我們的預(yù)期與協(xié)作者進(jìn)行交互。

順便說一句，當(dāng)我們編寫有關(guān)如何使用協(xié)作者的測試時(shí)，定義它們的接口是在將TDD用作設(shè)計(jì)工具而不僅僅是將其用作測試工具時(shí)。 我將在以后的博客文章中介紹。

好的，現(xiàn)在假設(shè)可以以不同的方式（即具有不同的可報(bào)告性決策）創(chuàng)建此貿(mào)易對象。 我們還希望使代碼更具可讀性，因此我們決定為Trade對象編寫一個(gè)生成器。 在這種情況下，我們還假設(shè)我們希望生成器也用于生產(chǎn)和測試代碼中。 在這種情況下，我們要測試驅(qū)動(dòng)器。

這是我通常在開發(fā)人員測試驅(qū)動(dòng)構(gòu)建器實(shí)現(xiàn)時(shí)發(fā)現(xiàn)的一個(gè)示例。

package org.craftedsw.testingbuilders;import static org.craftedsw.testingbuilders.TradeBuilder.aTrade;import static org.hamcrest.Matchers.is;import static org.junit.Assert.assertThat;import static org.mockito.Mockito.verify;import org.junit.Test;import org.junit.runner.RunWith;import org.mockito.Mock;import org.mockito.runners.MockitoJUnitRunner;@RunWith(MockitoJUnitRunner.class)public class TradeBuilderTest {private static final String TRADE_XML_MESSAGE = '<message >';@Mockprivate ReportabilityDecision reportabilityDecision;@Test public voidshould_create_a_trade_with_inbound_message() {Trade trade = aTrade().withInboundMessage(TRADE_XML_MESSAGE).build();assertThat(trade.getInboundMessage(), is(TRADE_XML_MESSAGE));}@Test public voidshould_create_a_trade_with_a_reportability_decision() {Trade trade = aTrade().withInboundMessage(TRADE_XML_MESSAGE).withReportabilityDecision(reportabilityDecision).build();trade.isReportable();verify(reportabilityDecision).isReportable(TRADE_XML_MESSAGE);}}

現(xiàn)在讓我們看看這些測試。 好消息是，這些測試是以開發(fā)人員想要閱讀它們的方式編寫的。 這也意味著他們正在“設(shè)計(jì)” TradeBuilder公共接口（公共方法）。 壞消息是他們?nèi)绾螌ζ溥M(jìn)行測試。

如果仔細(xì)看，構(gòu)建器的測試幾乎與TradeTest類中的測試相同。
您可能會(huì)說沒問題，因?yàn)闃?gòu)建器正在創(chuàng)建對象，并且測試應(yīng)該相似。 唯一的不同是，在TradeTest中我們手動(dòng)實(shí)例化對象，在TradeBuilderTest中我們使用構(gòu)建器實(shí)例化對象，但是斷言應(yīng)該相同，對嗎？ 對于我來說，首先我們要重復(fù)。 其次，TradeBuilderTest沒有顯示出它的真實(shí)意圖。 經(jīng)過多次重構(gòu)和探索不同的想法之后，在與團(tuán)隊(duì)中的一個(gè)人進(jìn)行配對編程時(shí)，我們想到了這種方法：

package org.craftedsw.testingbuilders;import static org.mockito.BDDMockito.given;import static org.mockito.Mockito.verify;import org.junit.Test;import org.junit.runner.RunWith;import org.mockito.InjectMocks;import org.mockito.Mock;import org.mockito.Spy;import org.mockito.runners.MockitoJUnitRunner;@RunWith(MockitoJUnitRunner.class)public class TradeBuilderTest {private static final String TRADE_XML_MESSAGE = '<message >';@Mock private ReportabilityDecision reportabilityDecision;@Mock private Trade trade;@Spy @InjectMocks TradeBuilder tradeBuilder;@Test public voidshould_create_a_trade_with_all_specified_attributes() {given(tradeBuilder.createTrade()).willReturn(trade);tradeBuilder.withInboundMessage(TRADE_XML_MESSAGE).withReportabilityDecision(reportabilityDecision).build();verify(trade).setInboundMessage(TRADE_XML_MESSAGE);verify(trade).setReportabilityDecision(reportabilityDecision);}}

因此，現(xiàn)在，TradeBuilderTest表達(dá)了TradeBuilder的期望，即調(diào)用build方法時(shí)的副作用。 我們希望它創(chuàng)建交易并設(shè)置其屬性。 TradeTest沒有重復(fù)項(xiàng)。 它留給TradeTest來保證Trade對象的正確行為。
為了完整起見，這是最后的TradeBuider類：

package org.craftedsw.testingbuilders;public class TradeBuilder {private String inboundMessage;private ReportabilityDecision reportabilityDecision;public static TradeBuilder aTrade() {return new TradeBuilder();}public TradeBuilder withInboundMessage(String inboundMessage) {this.inboundMessage = inboundMessage;return this;}public TradeBuilder withReportabilityDecision(ReportabilityDecision reportabilityDecision) {this.reportabilityDecision = reportabilityDecision;return this;}public Trade build() {Trade trade = createTrade();trade.setInboundMessage(inboundMessage);trade.setReportabilityDecision(reportabilityDecision);return trade;}Trade createTrade() {return new Trade();}}

Mockito和Hamcrest的組合功能非常強(qiáng)大，使我們能夠編寫更好，更易讀的測試。

參考：來自Crafts Software博客的JCG合作伙伴 Sandro Mancuso的Mockito和Hamcrest的測試驅(qū)動(dòng)構(gòu)建器 。

翻譯自: https://www.javacodegeeks.com/2012/06/test-driving-builders-with-mockito-and.html

總結(jié)

以上是生活随笔為你收集整理的Mockito和Hamcrest的试驾制造商的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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