mockito

過(guò)去，很多人問(wèn)我是否測(cè)試吸氣劑和吸氣劑（屬性，屬性等）。 他們還問(wèn)我是否測(cè)試我的建筑商。 在我看來(lái)，答案取決于情況。

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

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

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

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)門(mén)rade對(duì)象具有一個(gè)名為inboundMessage的屬性，具有相應(yīng)的getter和setter，并且在isReportable業(yè)務(wù)方法中還使用了一個(gè)協(xié)作者（reportabilityDecision，通過(guò)setter注入）。

我多次見(jiàn)過(guò)的“測(cè)試” setReportabilityDecision方法的常見(jiàn)方法是引入getReportabilityDecision方法，該方法返回reportabilityDecision（協(xié)作者）對(duì)象。

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

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

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

這是我通常在開(kāi)發(fā)人員測(cè)試驅(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)在讓我們看看這些測(cè)試。 好消息是，測(cè)試以開(kāi)發(fā)人員希望閱讀的方式編寫(xiě)。 這也意味著他們正在“設(shè)計(jì)” TradeBuilder公共接口（公共方法）。 壞消息是他們?nèi)绾螠y(cè)試它。

如果仔細(xì)看，構(gòu)建器的測(cè)試與TradeTest類(lèi)中的測(cè)試幾乎相同。
您可能會(huì)說(shuō)沒(méi)問(wèn)題，因?yàn)闃?gòu)建器正在創(chuàng)建對(duì)象，并且測(cè)試應(yīng)該相似。 唯一的不同是，在TradeTest中我們手動(dòng)實(shí)例化對(duì)象，在TradeBuilderTest中我們使用構(gòu)建器實(shí)例化對(duì)象，但是斷言應(yīng)該相同，對(duì)嗎？
對(duì)我來(lái)說(shuō)，首先我們要重復(fù)。 其次，TradeBuilderTest沒(méi)有顯示出它的真實(shí)意圖。 經(jīng)過(guò)多次重構(gòu)和探索不同的想法之后，在與團(tuán)隊(duì)中的一個(gè)人進(jìn)行配對(duì)編程時(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沒(méi)有重復(fù)項(xiàng)。 它留給TradeTest來(lái)保證Trade對(duì)象的正確行為。
為了完善起見(jiàn)，這是最后的TradeBuider類(lèi)：

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的結(jié)合非常強(qiáng)大，使我們能夠編寫(xiě)更好，更易讀的測(cè)試。

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

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

mockito

總結(jié)

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

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