junit mockito

可執(zhí)行規(guī)范是也可以用作設(shè)計(jì)規(guī)范的測(cè)試。 通過啟用通用語言（在DDD世界中，這也稱為無處不在的語言 ），它們使技術(shù)和業(yè)務(wù)團(tuán)隊(duì)能夠進(jìn)入同一頁(yè)面。 它們充當(dāng)代碼的未來維護(hù)者的文檔。
在本文中，我們將看到一種編寫自動(dòng)測(cè)試的自以為是的方式，該方法也可以用作可執(zhí)行規(guī)范。

讓我們從一個(gè)例子開始。 假設(shè)我們正在為企業(yè)創(chuàng)建會(huì)計(jì)系統(tǒng)。 該系統(tǒng)將允許其用戶將收入和支出記錄到不同的帳戶中。 在用戶開始記錄收入和支出之前，他們應(yīng)該能夠?qū)⑿聨籼砑拥较到y(tǒng)中。 假設(shè)“添加新帳戶”用例的規(guī)范如下所示–

場(chǎng)景1

給定帳戶不存在 用戶添加新帳戶時(shí) 然后添加的帳戶具有給定的名稱 然后添加的帳戶具有給定的初始余額 然后添加的帳戶具有用戶的ID

方案2

給定帳戶不存在 當(dāng)用戶添加初始余額為負(fù)的新帳戶時(shí) 然后添加新帳戶失敗

場(chǎng)景3

具有相同名稱的給定帳戶 用戶添加新帳戶時(shí) 然后添加新帳戶失敗

為了創(chuàng)建一個(gè)新帳戶，用戶需要在系統(tǒng)中輸入一個(gè)帳戶名和一個(gè)初始余額。 如果不存在具有給定名稱的帳戶并且給定的初始余額為正，則系統(tǒng)將創(chuàng)建該帳戶。

我們將首先寫下一個(gè)測(cè)試，該測(cè)試將捕獲第一個(gè)場(chǎng)景的第一個(gè)“ Given-When-Then”部分。 這就是它的樣子–

class AddNewAccountTest { @Test @DisplayName ( "Given account does not exist When user adds a new account Then added account has the given name" ) void accountAddedWithGivenName() { ????} }

@DisplayName批注是在JUnit 5中引入的。它為測(cè)試分配了易于理解的名稱。 這是我們執(zhí)行此測(cè)試時(shí)看到的標(biāo)簽，例如在像IntelliJ IDEA這樣的IDE中。

現(xiàn)在，我們將創(chuàng)建一個(gè)類，負(fù)責(zé)添加帳戶

class AddNewAccountService { void addNewAccount(String accountName) { } }

該類定義一個(gè)接受帳戶名稱并負(fù)責(zé)創(chuàng)建帳戶的方法，即將其保存到持久數(shù)據(jù)存儲(chǔ)中。 由于我們決定將此類稱為AddNewAccountService，因此我們還將測(cè)試重命名為AddNewAccountServiceTest以遵循JUnit世界中使用的命名約定。

現(xiàn)在，我們可以繼續(xù)編寫測(cè)試了–

class AddNewAccountServiceTest { @Test @DisplayName ( "Given account does not exist When user adds a new account Then added account has the given name" ) void accountAddedWithGivenName() { AddNewAccountService accountService = new AddNewAccountService(); accountService.addNewAccount( "test account" ); ????// What to test? } }

我們應(yīng)該測(cè)試/驗(yàn)證什么以確保正確實(shí)施該方案？ 如果再次閱讀我們的規(guī)范，很明顯，我們想創(chuàng)建一個(gè)具有用戶指定名稱的“帳戶”，因此我們應(yīng)該在此處進(jìn)行測(cè)試。 為此，我們必須首先創(chuàng)建一個(gè)代表帳戶的類-

@AllArgsConstructor class Account { private String name; }

Account類只有一個(gè)名為name的屬性。 它將具有其他字段，例如用戶ID和余額，但是我們目前尚未對(duì)其進(jìn)行測(cè)試，因此我們不會(huì)立即將它們添加到類中。

現(xiàn)在，我們已經(jīng)創(chuàng)建了Account類，如何保存它，更重要的是，我們?nèi)绾螠y(cè)試所保存的帳戶具有用戶指定的名稱？ 有許多方法可以做到這一點(diǎn)，而我的首選方法是定義一個(gè)接口，該接口將封裝此保存操作。 讓我們繼續(xù)創(chuàng)建它–

interface SaveAccountPort { void saveAccount(Account account); }

AddNewAccountService將通過構(gòu)造函數(shù)注入注入該接口的實(shí)現(xiàn)–

@RequiredArgsConstructor class AddNewAccountService { private final SaveAccountPort saveAccountPort; void addNewAccount(String accountName) { } }

為了進(jìn)行測(cè)試，我們將在Mockito的幫助下創(chuàng)建一個(gè)模擬實(shí)現(xiàn)，這樣我們就不必?fù)?dān)心實(shí)際的實(shí)現(xiàn)細(xì)節(jié)了–

@ExtendWith (MockitoExtension. class ) class AddNewAccountServiceTest { @Mock private SaveAccountPort saveAccountPort; @Test @DisplayName ( "Given account does not exist When user adds a new account Then added account has the given name" ) void accountAddedWithGivenName() { AddNewAccountService accountService = new AddNewAccountService(saveAccountPort); accountService.addNewAccount( "test account" ); ????// What to test? } }

我們的測(cè)試設(shè)置現(xiàn)已完成。 現(xiàn)在，我們希望我們的測(cè)試方法（AddNewAccountService類的addNewAccount方法）調(diào)用SaveAccountPort的saveAccount方法，并將Account對(duì)象的名稱設(shè)置為傳遞給該方法的對(duì)象。 讓我們?cè)跍y(cè)試中對(duì)此進(jìn)行整理–

@ExtendWith (MockitoExtension. class ) class AddNewAccountServiceTest { @Mock private SaveAccountPort saveAccountPort; @Captor private ArgumentCaptor<Account> accountArgumentCaptor; @Test @DisplayName ( "Given account does not exist When user adds a new account Then added account has the given name" ) void accountAddedWithGivenName() { AddNewAccountService accountService = new AddNewAccountService(saveAccountPort); accountService.addNewAccount( "test account" ); BDDMockito.then(saveAccountPort).should().saveAccount(accountArgumentCaptor.capture()); BDDAssertions.then(accountArgumentCaptor.getValue().getName()).isEqualTo( "test account" ); } }

下面的行–

BDDMockito.then(saveAccountPort).should().saveAccount(accountArgumentCaptor.capture());

驗(yàn)證一旦調(diào)用了被測(cè)試方法，即已調(diào)用SaveAccountPort的saveAccount方法。 我們還使用參數(shù)捕獲器捕獲傳遞到saveAccount方法的帳戶參數(shù)。 下一行–

BDDAssertions.then(accountArgumentCaptor.getValue().getName()).isEqualTo( "test account" );

然后驗(yàn)證捕獲的帳戶參數(shù)與測(cè)試中通過的名稱相同。

為了使此測(cè)試通過，在我們的被測(cè)方法中需要的最少代碼如下：

@RequiredArgsConstructor class AddNewAccountService { private final SaveAccountPort saveAccountPort; void addNewAccount(String accountName) { saveAccountPort.saveAccount( new Account(accountName)); } }

這樣，我們的測(cè)試開始通過！

讓我們繼續(xù)進(jìn)行第一個(gè)方案的第二個(gè)“ Then”部分，它說–

然后添加的帳戶具有給定的初始余額

讓我們寫另一個(gè)測(cè)試來驗(yàn)證這一部分–

@Test @DisplayName ( "Given account does not exist When user adds a new account Then added account has the given initial balance" ) void accountAddedWithGivenInitialBalance() { AddNewAccountService accountService = new AddNewAccountService(saveAccountPort); accountService.addNewAccount( "test account" , "56.0" ); ??BDDMockito.then(saveAccountPort).should().saveAccount(accountArgumentCaptor.capture()); BDDAssertions.then(accountArgumentCaptor.getValue().getBalance()) .isEqualTo( new BigDecimal( "56.0" )); }

我們修改了addNewAccount方法以接受初始余額作為第二個(gè)參數(shù)。 我們還在帳戶對(duì)象中添加了一個(gè)稱為余額的新字段，該字段能夠存儲(chǔ)帳戶余額–

@AllArgsConstructor @Getter class Account { private String name; private BigDecimal balance; }

由于我們更改了addNewAccount方法的簽名，因此我們還必須修改我們的第一個(gè)測(cè)試–

@Test @DisplayName ( "Given account does not exist When user adds a new account Then added account has the given name" ) void accountAddedWithGivenName() { AddNewAccountService accountService = new AddNewAccountService(saveAccountPort); accountService.addNewAccount( "test account" , "1" ); BDDMockito.then(saveAccountPort).should().saveAccount(accountArgumentCaptor.capture()); BDDAssertions.then(accountArgumentCaptor.getValue().getName()).isEqualTo( "test account" ); }

如果我們現(xiàn)在運(yùn)行新測(cè)試，它將由于我們尚未實(shí)現(xiàn)該功能而失敗。 現(xiàn)在就開始吧–

void addNewAccount(String accountName, String initialBalance) { saveAccountPort.saveAccount( new Account(accountName, new BigDecimal(initialBalance))); }

我們的兩個(gè)測(cè)試現(xiàn)在都應(yīng)該通過。

由于我們已經(jīng)進(jìn)行了一些測(cè)試，現(xiàn)在該看看我們的實(shí)現(xiàn)，看看是否可以做得更好。 由于我們的AddNewAccountService非常簡(jiǎn)單，因此我們無需在此做任何事情。 對(duì)于我們的測(cè)試，我們可以消除測(cè)試設(shè)置代碼中的重復(fù)項(xiàng)–兩個(gè)測(cè)試都實(shí)例化AddNewAccountService的實(shí)例，并以相同的方式在其上調(diào)用addNewAccount方法。 刪除還是保留重復(fù)項(xiàng)取決于我們的測(cè)試編寫方式-如果我們想使每個(gè)測(cè)試盡可能獨(dú)立，那么就讓它們保持原樣。 但是，如果我們對(duì)使用通用的測(cè)試設(shè)置代碼感到滿意，則可以按以下方式更改測(cè)試

@ExtendWith (MockitoExtension. class ) @DisplayName ( "Given account does not exist When user adds a new account" ) class AddNewAccountServiceTest { private static final String ACCOUNT_NAME = "test account" ; private static final String INITIAL_BALANCE = "56.0" ; @Mock private SaveAccountPort saveAccountPort; @Captor private ArgumentCaptor<Account> accountArgumentCaptor; @BeforeEach void setup() { AddNewAccountService accountService = new AddNewAccountService(saveAccountPort); accountService.addNewAccount(ACCOUNT_NAME, INITIAL_BALANCE); } @Test @DisplayName ( "Then added account has the given name" ) void accountAddedWithGivenName() { BDDMockito.then(saveAccountPort).should().saveAccount(accountArgumentCaptor.capture()); BDDAssertions.then(accountArgumentCaptor.getValue().getName()).isEqualTo(ACCOUNT_NAME); } @Test @DisplayName ( "Then added account has the given initial balance" ) void accountAddedWithGivenInitialBalance() { BDDMockito.then(saveAccountPort).should().saveAccount(accountArgumentCaptor.capture()); BDDAssertions.then(accountArgumentCaptor.getValue().getBalance()) .isEqualTo( new BigDecimal(INITIAL_BALANCE)); } }

請(qǐng)注意，我們還提取了@DisplayName的公共部分，并將其放在測(cè)試類的頂部。 如果我們不愿意這樣做，我們也可以保留原樣。

由于我們有多個(gè)通過的測(cè)試，因此從現(xiàn)在開始，每一次失敗的測(cè)試通過，我們都會(huì)停一會(huì)兒，看看我們的實(shí)現(xiàn)，并嘗試對(duì)其進(jìn)行改進(jìn)。 總而言之，我們的實(shí)施過程現(xiàn)在將包括以下步驟-

在確保現(xiàn)有測(cè)試持續(xù)通過的同時(shí)添加失敗的測(cè)試

通過失敗的測(cè)試

暫停片刻，然后嘗試改善實(shí)施（代碼和測(cè)試）

繼續(xù)，我們現(xiàn)在需要使用創(chuàng)建的帳戶存儲(chǔ)用戶ID。 按照我們的方法，我們將首先編寫一個(gè)失敗的測(cè)試以捕獲此錯(cuò)誤，然后添加使失敗的測(cè)試通過的最少代碼量。 一旦失敗的測(cè)試開始通過，這就是實(shí)現(xiàn)的樣子

@ExtendWith (MockitoExtension. class ) @DisplayName ( "Given account does not exist When user adds a new account" ) class AddNewAccountServiceTest { private static final String ACCOUNT_NAME = "test account" ; private static final String INITIAL_BALANCE = "56.0" ; private static final String USER_ID = "some id" ; private Account savedAccount; @BeforeEach void setup() { AddNewAccountService accountService = new AddNewAccountService(saveAccountPort); accountService.addNewAccount(ACCOUNT_NAME, INITIAL_BALANCE, USER_ID); BDDMockito.then(saveAccountPort).should().saveAccount(accountArgumentCaptor.capture()); savedAccount = accountArgumentCaptor.getValue(); } ??// Other tests..... @Test @DisplayName ( "Then added account has user's id" ) void accountAddedWithUsersId() { BDDAssertions.then(accountArgumentCaptor.getValue().getUserId()).isEqualTo(USER_ID); } } @RequiredArgsConstructor class AddNewAccountService { private final SaveAccountPort saveAccountPort; void addNewAccount(String accountName, String initialBalance, String userId) { saveAccountPort.saveAccount( new Account(accountName, new BigDecimal(initialBalance), userId)); } } @AllArgsConstructor @Getter class Account { private String name; private BigDecimal balance; private String userId; }

既然所有測(cè)試都通過了，那就是改進(jìn)的時(shí)間了！ 請(qǐng)注意，addNewAccount方法已經(jīng)接受了三個(gè)參數(shù)。 隨著我們引入越來越多的帳戶屬性，其參數(shù)列表也將開始增加。 我們可以引入一個(gè)參數(shù)對(duì)象來避免這種情況

@RequiredArgsConstructor class AddNewAccountService { private final SaveAccountPort saveAccountPort; void addNewAccount(AddNewAccountCommand command) { saveAccountPort.saveAccount( new Account( command.getAccountName(), new BigDecimal(command.getInitialBalance()), command.getUserId() ) ); } @Builder @Getter static class AddNewAccountCommand { private final String userId; private final String accountName; private final String initialBalance; } } @ExtendWith (MockitoExtension. class ) @DisplayName ( "Given account does not exist When user adds a new account" ) class AddNewAccountServiceTest { // Fields..... @BeforeEach void setup() { AddNewAccountService accountService = new AddNewAccountService(saveAccountPort); AddNewAccountCommand command = AddNewAccountCommand.builder() .accountName(ACCOUNT_NAME) .initialBalance(INITIAL_BALANCE) .userId(USER_ID) .build(); accountService.addNewAccount(command); BDDMockito.then(saveAccountPort).should().saveAccount(accountArgumentCaptor.capture()); savedAccount = accountArgumentCaptor.getValue(); } // Remaining Tests..... }

如果現(xiàn)在在我的IDEA中運(yùn)行測(cè)試，這就是我所看到的–

當(dāng)我們嘗試在此視圖中閱讀測(cè)試描述時(shí)，我們已經(jīng)可以很好地了解“添加新帳戶”用例及其工作方式。

好的，讓我們繼續(xù)進(jìn)行用例的第二種情況，這是一個(gè)驗(yàn)證規(guī)則

給定帳戶不存在

當(dāng)用戶添加初始余額為負(fù)的新帳戶時(shí)

然后添加新帳戶失敗

讓我們編寫一個(gè)新的測(cè)試來嘗試捕獲這一點(diǎn)–

@ExtendWith (MockitoExtension. class ) @DisplayName ( "Given account does not exist When user adds a new account" ) class AddNewAccountServiceTest { // Other tests @Test @DisplayName ( "Given account does not exist When user adds a new account with negative initial balance Then add new account fails" ) void addNewAccountFailsWithNegativeInitialBalance() { AddNewAccountService accountService = new AddNewAccountService(saveAccountPort); AddNewAccountCommand command = AddNewAccountCommand.builder().initialBalance( "-56.0" ).build(); AddNewAccountCommand command = AddNewAccountCommand.builder().initialBalance( ).build(); accountService.addNewAccount(command); BDDMockito.then(saveAccountPort).shouldHaveNoInteractions(); } }

我們可以通過幾種方法在服務(wù)中實(shí)施驗(yàn)證。 我們可以拋出一個(gè)異常詳細(xì)說明驗(yàn)證失敗，或者我們可以返回一個(gè)包含錯(cuò)誤詳細(xì)信息的錯(cuò)誤對(duì)象。 在此示例中，如果驗(yàn)證失敗，我們將拋出異常–

@Test @DisplayName ( "Given account does not exist When user adds a new account with negative initial balance Then add new account fails" ) void addNewAccountFailsWithNegativeInitialBalance() { AddNewAccountService accountService = new AddNewAccountService(saveAccountPort); AddNewAccountCommand command = AddNewAccountCommand.builder().initialBalance( "-56.0" ).build(); AddNewAccountCommand command = AddNewAccountCommand.builder().initialBalance( ).build(); assertThatExceptionOfType(IllegalArgumentException. class ) .isThrownBy(() -> accountService.addNewAccount(command)); BDDMockito.then(saveAccountPort).shouldHaveNoInteractions(); }

此測(cè)試驗(yàn)證以負(fù)余額調(diào)用addNewAccount方法時(shí)是否引發(fā)異常。 它還可以確保在這種情況下，我們的代碼不會(huì)調(diào)用SaveAccountPort的任何方法。 在我們開始修改我們的服務(wù)以通過此測(cè)試之前，我們必須重構(gòu)一下我們的測(cè)試設(shè)置代碼。 這是因?yàn)樵谖覀冎暗闹貥?gòu)中，我們將通用測(cè)試設(shè)置代碼移到了一個(gè)方法中，該方法現(xiàn)在可以在每次測(cè)試之前運(yùn)行–

@BeforeEach void setup() { AddNewAccountService accountService = new AddNewAccountService(saveAccountPort); AddNewAccountCommand command = AddNewAccountCommand.builder() .accountName(ACCOUNT_NAME) .initialBalance(INITIAL_BALANCE) .userId(USER_ID) .build(); accountService.addNewAccount(command); BDDMockito.then(saveAccountPort).should().saveAccount(accountArgumentCaptor.capture()); savedAccount = accountArgumentCaptor.getValue(); }

現(xiàn)在，此設(shè)置代碼與我們剛剛添加的新測(cè)試直接沖突–在每次測(cè)試之前，它將始終使用有效的命令對(duì)象調(diào)用addNewAccount方法，從而導(dǎo)致調(diào)用SaveAccountPort的saveAccount方法，從而導(dǎo)致新測(cè)試失敗。

為了解決此問題，我們將在測(cè)試類中創(chuàng)建一個(gè)嵌套類，在其中我們將移動(dòng)現(xiàn)有的設(shè)置代碼和通過測(cè)試–

@ExtendWith (MockitoExtension. class ) @DisplayName ( "Given account does not exist" ) class AddNewAccountServiceTest { @Mock private SaveAccountPort saveAccountPort; private AddNewAccountService accountService; @BeforeEach void setUp() { accountService = new AddNewAccountService(saveAccountPort); } @Nested @DisplayName ( "When user adds a new account" ) class WhenUserAddsANewAccount { private static final String ACCOUNT_NAME = "test account" ; private static final String INITIAL_BALANCE = "56.0" ; private static final String USER_ID = "some id" ; private Account savedAccount; @Captor private ArgumentCaptor<Account> accountArgumentCaptor; @BeforeEach void setUp() { AddNewAccountCommand command = AddNewAccountCommand.builder() .accountName(ACCOUNT_NAME) .initialBalance(INITIAL_BALANCE) .userId(USER_ID) .build(); accountService.addNewAccount(command); BDDMockito.then(saveAccountPort).should().saveAccount(accountArgumentCaptor.capture()); savedAccount = accountArgumentCaptor.getValue(); } @Test @DisplayName ( "Then added account has the given name" ) void accountAddedWithGivenName() { BDDAssertions.then(savedAccount.getName()).isEqualTo(ACCOUNT_NAME); } @Test @DisplayName ( "Then added account has the given initial balance" ) void accountAddedWithGivenInitialBalance() { BDDAssertions.then(savedAccount.getBalance()).isEqualTo( new BigDecimal(INITIAL_BALANCE)); } @Test @DisplayName ( "Then added account has user's id" ) void accountAddedWithUsersId() { BDDAssertions.then(accountArgumentCaptor.getValue().getUserId()).isEqualTo(USER_ID); } } ??@Test @DisplayName ( "When user adds a new account with negative initial balance Then add new account fails" ) void addNewAccountFailsWithNegativeInitialBalance() { AddNewAccountCommand command = AddNewAccountCommand.builder() .initialBalance( "-56.0" ) .build(); assertThatExceptionOfType(IllegalArgumentException. class ) .isThrownBy(() -> accountService.addNewAccount(command)); BDDMockito.then(saveAccountPort).shouldHaveNoInteractions(); } }

這是我們采取的重構(gòu)步驟–

我們創(chuàng)建了一個(gè)內(nèi)部類，然后用JUnit 5的@Nested批注標(biāo)記內(nèi)部類。

我們破壞了最外面的測(cè)試類的@DisplayName標(biāo)簽，并將“當(dāng)用戶添加新帳戶時(shí)”部分移到了新引入的內(nèi)部類中。 我們這樣做的原因是因?yàn)榇藘?nèi)部類將包含一組測(cè)試，這些測(cè)試將驗(yàn)證/驗(yàn)證與有效帳戶創(chuàng)建方案有關(guān)的行為。

我們將相關(guān)的設(shè)置代碼和字段/常量移到了這個(gè)內(nèi)部類中。

我們從新測(cè)試中刪除了“給定帳戶不存在”部分。 這是因?yàn)樽钔鈱訙y(cè)試類上的@DisplayName已包含此內(nèi)容，因此這里再也沒有包含它。

現(xiàn)在是在IntelliJ IDEA中運(yùn)行測(cè)試時(shí)的樣子，

從屏幕截圖中可以看到，我們的測(cè)試標(biāo)簽也按照我們?cè)跍y(cè)試代碼中創(chuàng)建的結(jié)構(gòu)很好地進(jìn)行了分組和縮進(jìn)。 現(xiàn)在，讓我們修改服務(wù)以使失敗的測(cè)試通過–

void addNewAccount(AddNewAccountCommand command) { BigDecimal initialBalance = new BigDecimal(command.getInitialBalance()); if (initialBalance.compareTo(BigDecimal.ZERO) < 0 ) { throw new IllegalArgumentException( "Initial balance of an account cannot be negative" ); } saveAccountPort.saveAccount( new Account( command.getAccountName(), initialBalance, command.getUserId() ) ); }

這樣，我們所有的測(cè)試再次開始通過。 下一步是尋找可能的方法來改進(jìn)現(xiàn)有的實(shí)現(xiàn)。 如果沒有，那么我們將繼續(xù)執(zhí)行最終方案，這也是一個(gè)驗(yàn)證規(guī)則–

具有相同名稱的給定帳戶

用戶添加新帳戶時(shí)

然后添加新帳戶失敗

和往常一樣，讓我們??編寫一個(gè)測(cè)試來捕獲這一點(diǎn)–

@Test @DisplayName ( "Given account with the same name exists When user adds a new account Then add new account fails" ) void addNewAccountFailsForDuplicateAccounts() { AddNewAccountCommand command = AddNewAccountCommand.builder() .accountName( "existing name" ) .build(); AddNewAccountService accountService = new AddNewAccountService(saveAccountPort); assertThatExceptionOfType(IllegalArgumentException. class ) .isThrownBy(() -> accountService.addNewAccount(command)); BDDMockito.then(saveAccountPort).shouldHaveNoInteractions(); }

我們現(xiàn)在必須弄清的第一件事是如何找到現(xiàn)有帳戶。 由于這將涉及查詢我們的持久數(shù)據(jù)存儲(chǔ)，因此我們將引入一個(gè)接口–

public interface FindAccountPort { Account findAccountByName(String accountName); }

并將其注入我們的AddNewAccountService –

@RequiredArgsConstructor class AddNewAccountService { private final SaveAccountPort saveAccountPort; private final FindAccountPort findAccountPort; ??// Rest of the code }

并修改我們的測(cè)試–

@Test @DisplayName ( "Given account with the same name exists When user adds a new account Then add new account fails" ) void addNewAccountFailsForDuplicateAccounts() { String existingAccountName = "existing name" ; AddNewAccountCommand command = AddNewAccountCommand.builder() .initialBalance( "0" ) .accountName(existingAccountName) .build(); given(findAccountPort.findAccountByName(existingAccountName)).willReturn(mock(Account. class )); AddNewAccountService accountService = new AddNewAccountService(saveAccountPort, findAccountPort); assertThatExceptionOfType(IllegalArgumentException. class ) .isThrownBy(() -> accountService.addNewAccount(command)); BDDMockito.then(saveAccountPort).shouldHaveNoInteractions(); }

對(duì)AddNewAccountService的最后更改也將需要對(duì)現(xiàn)有測(cè)試進(jìn)行更改，主要是在我們實(shí)例化該類的實(shí)例的位置。 但是，我們將做的改變不止于此–

@ExtendWith (MockitoExtension. class ) class AddNewAccountServiceTest { @Mock private SaveAccountPort saveAccountPort; @Mock private FindAccountPort findAccountPort; @Nested @DisplayName ( "Given account does not exist" ) class AccountDoesNotExist { private AddNewAccountService accountService; @BeforeEach void setUp() { accountService = new AddNewAccountService(saveAccountPort, findAccountPort); } @Nested @DisplayName ( "When user adds a new account" ) class WhenUserAddsANewAccount { private static final String ACCOUNT_NAME = "test account" ; private static final String INITIAL_BALANCE = "56.0" ; private static final String USER_ID = "some id" ; private Account savedAccount; @Captor private ArgumentCaptor<Account> accountArgumentCaptor; @BeforeEach void setUp() { AddNewAccountCommand command = AddNewAccountCommand.builder() .accountName(ACCOUNT_NAME) .initialBalance(INITIAL_BALANCE) .userId(USER_ID) .build(); accountService.addNewAccount(command); BDDMockito.then(saveAccountPort).should().saveAccount(accountArgumentCaptor.capture()); savedAccount = accountArgumentCaptor.getValue(); } @Test @DisplayName ( "Then added account has the given name" ) void accountAddedWithGivenName() { BDDAssertions.then(savedAccount.getName()).isEqualTo(ACCOUNT_NAME); } @Test @DisplayName ( "Then added account has the given initial balance" ) void accountAddedWithGivenInitialBalance() { BDDAssertions.then(savedAccount.getBalance()).isEqualTo( new BigDecimal(INITIAL_BALANCE)); } @Test @DisplayName ( "Then added account has user's id" ) void accountAddedWithUsersId() { BDDAssertions.then(accountArgumentCaptor.getValue().getUserId()).isEqualTo(USER_ID); } } @Test @DisplayName ( "When user adds a new account with negative initial balance Then add new account fails" ) void addNewAccountFailsWithNegativeInitialBalance() { AddNewAccountCommand command = AddNewAccountCommand.builder() .initialBalance( "-56.0" ) .build(); assertThatExceptionOfType(IllegalArgumentException. class ) .isThrownBy(() -> accountService.addNewAccount(command)); BDDMockito.then(saveAccountPort).shouldHaveNoInteractions(); } } @Test @DisplayName ( "Given account with the same name exists When user adds a new account Then add new account fails" ) void addNewAccountFailsForDuplicateAccounts() { String existingAccountName = "existing name" ; AddNewAccountCommand command = AddNewAccountCommand.builder() .initialBalance( "0" ) .accountName(existingAccountName) .build(); given(findAccountPort.findAccountByName(existingAccountName)).willReturn(mock(Account. class )); AddNewAccountService accountService = new AddNewAccountService(saveAccountPort, findAccountPort); assertThatExceptionOfType(IllegalArgumentException. class ) .isThrownBy(() -> accountService.addNewAccount(command)); BDDMockito.then(saveAccountPort).shouldHaveNoInteractions(); } }

這是我們所做的–

我們創(chuàng)建了另一個(gè)內(nèi)部類，將其標(biāo)記為@Nested，并將現(xiàn)有的通過測(cè)試移入其中。 這組測(cè)試測(cè)試在不存在具有給定名稱的帳戶時(shí)添加新帳戶的行為。

我們已將測(cè)試設(shè)置代碼移至新引入的內(nèi)部類中，因?yàn)樗鼈円才c“不存在具有給定名稱的帳戶”的情況有關(guān)。

出于與上述相同的原因，我們還將@DisplayName注釋從頂級(jí)測(cè)試類移動(dòng)到了新引入的內(nèi)部類。

重構(gòu)之后，我們快速運(yùn)行測(cè)試以查看一切是否按預(yù)期工作（測(cè)試失敗，通過測(cè)試通過），然后繼續(xù)修改我們的服務(wù)–

@RequiredArgsConstructor class AddNewAccountService { private final SaveAccountPort saveAccountPort; private final FindAccountPort findAccountPort; void addNewAccount(AddNewAccountCommand command) { BigDecimal initialBalance = new BigDecimal(command.getInitialBalance()); if (initialBalance.compareTo(BigDecimal.ZERO) < 0 ) { throw new IllegalArgumentException( "Initial balance of an account cannot be negative" ); } if (findAccountPort.findAccountByName(command.getAccountName()) != null ) { throw new IllegalArgumentException( "An account with given name already exists" ); } saveAccountPort.saveAccount( new Account( command.getAccountName(), initialBalance, command.getUserId() ) ); } @Builder @Getter static class AddNewAccountCommand { private final String userId; private final String accountName; private final String initialBalance; } }

我們所有的測(cè)試現(xiàn)在都是綠色的–

由于我們的用例實(shí)現(xiàn)現(xiàn)已完成，因此我們將最后一次查看實(shí)現(xiàn)，以查看是否可以進(jìn)行任何改進(jìn)。 如果沒有，那么我們的用例實(shí)現(xiàn)現(xiàn)在就完成了！

總而言之，這就是我們?cè)诒疚闹兴龅抹C

我們已經(jīng)寫下了要實(shí)現(xiàn)的用例

我們添加了一個(gè)失敗的測(cè)試，并使用易于理解的名稱進(jìn)行標(biāo)記

我們添加了使測(cè)試通過失敗所需的最少代碼量

一旦我們進(jìn)行了一項(xiàng)以上的測(cè)試，在通過每項(xiàng)失敗的測(cè)試之后，我們查看了實(shí)現(xiàn)并試圖對(duì)其進(jìn)行改進(jìn)

在編寫測(cè)試時(shí)，我們嘗試以某種方式編寫測(cè)試，以使用例規(guī)范反映在測(cè)試代碼中。 為此，我們使用了–

@DisplayName批注為我們的測(cè)試分配易于理解的名稱

@Nested用于按層次結(jié)構(gòu)將相關(guān)測(cè)試分組，以反映我們的用例設(shè)置

使用了Mockito和AssertJ的BDD驅(qū)動(dòng)的API來驗(yàn)證預(yù)期的行為

我們什么時(shí)候應(yīng)該遵循這種編寫自動(dòng)化測(cè)試的風(fēng)格？ 該問題的答案與軟件工程中的其他所有用法問題相同-視情況而定。 當(dāng)我使用具有復(fù)雜業(yè)務(wù)/域規(guī)則的應(yīng)用程序時(shí)，我個(gè)人更喜歡這種樣式，該規(guī)則需要長(zhǎng)期維護(hù)，為此需要與業(yè)務(wù)部門緊密合作，以及許多其他因素（例如，應(yīng)用程序）架構(gòu)，團(tuán)隊(duì)采用率等）。

與往常一樣，完整的示例已提交給Github 。

直到下一次！

翻譯自: https://www.javacodegeeks.com/2020/04/clean-code-from-the-trenches-writing-executable-specifications-with-junit-5-mockito-and-assertj.html

junit mockito

總結(jié)

以上是生活随笔為你收集整理的junit mockito_从工作中清除代码–使用JUnit 5，Mockito和AssertJ编写可执行规范的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

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