Java幾種常用的斷言風(fēng)格你怎么選
日常工作中,不管你是寫Unit Test,還是采用TDD的編程方式進(jìn)行開發(fā),都會遇到斷言。而斷言的風(fēng)格常見的會有Assert、BDD風(fēng)格,對于這些常見的斷言風(fēng)格你怎么選擇呢?
01 Assert風(fēng)格
JUnit中提供了這樣的assert斷言風(fēng)格,例如:
void should_be_unlocked_when_insert_coin_given_a_entrance_machine_with_locked_state() { EntranceMachine entranceMachine = new EntranceMachine(EntranceMachineState.LOCKED); String result = entranceMachine.execute(Action.INSERT_COIN); assertEquals("opened", result); assertEquals(EntranceMachineState, entranceMachineState.UNLOCKED); }
Hamcrest和AssertJ都提供了assertThat()這樣風(fēng)格的斷言,例如:
AssertJ提供的assertThat()的斷言語法
void should_be_unlocked_when_insert_coin_given_a_entrance_machine_with_locked_state() { EntranceMachine entranceMachine = new EntranceMachine(EntranceMachineState.LOCKED); String result = entranceMachine.execute(Action.INSERT_COIN); assertThat(result).isEqualsTo("opened"); assertThat(EntranceMachineState).isEqualsTo(entranceMachineState.UNLOCKED); }
Hamcrest提供的assertThat()斷言語法
void should_be_unlocked_when_insert_coin_given_a_entrance_machine_with_locked_state() { EntranceMachine entranceMachine = new EntranceMachine(EntranceMachineState.LOCKED); String result = entranceMachine.execute(Action.INSERT_COIN); assertThat(result, is("opened")); assertThat(EntranceMachineState, is(entranceMachineState.UNLOCKED)); }
對比上面三種斷言語法,因?yàn)閳鼍昂唵?,所以結(jié)果差異并不是很大。對于我個人更加偏向于使用AssertJ提供的斷言風(fēng)格。因?yàn)檫@種風(fēng)格避免JUnit提供的斷言中經(jīng)常遇到的問題,expected在前還是actural在前的問題。相比于Hamcrest的斷言風(fēng)格,在日常工作中綜合對比發(fā)現(xiàn)AssertJ的更加清晰,畢竟AssertJ中assertThat只需要接收一個參數(shù),而不用關(guān)注括號是否對齊的問題。
日常工作中如果使用TDD,且場景適當(dāng)(例如上面例子),那么Hamcreate和AssertJ的差別不是很大。JUnit5默認(rèn)提供了Hamcreate的斷言,不需要額外的再引入其他依賴。
02 BDD風(fēng)格
代碼的可讀性越來越收到開發(fā)者的重視。測試代碼的可讀性同樣重要,為了讓測試代碼結(jié)構(gòu)清晰,便于業(yè)務(wù)邏輯變動時(shí)能快讀讀懂測試的上下文,很多開發(fā)團(tuán)隊(duì)約定了BDD的風(fēng)格來組織測試代碼。其中包含兩部分的約定:測試方法名的約定,測試代碼段落的約定。
例如前面的例子:
void should_be_unlocked_when_insert_coin_given_a_entrance_machine_with_locked_state() { ... }
雖然方法名很長,但是通過方法名我們能夠快速知道測試類中有哪些測試,通過方法名我們能夠清晰的當(dāng)前測試的上下文,在測什么,期望的結(jié)果什么。通過方法名而不是通過比方法名長很多的代碼段來獲取測試在測什么的信息,畢竟閱讀代碼時(shí)間和修改代碼時(shí)間可能是10:1,甚至20:1。所以團(tuán)隊(duì)約定BDD的風(fēng)格組織在后續(xù)修改代碼時(shí),是受益良多的。
當(dāng)需要也帶具體的測試代碼的時(shí)候,團(tuán)隊(duì)發(fā)現(xiàn)按照BDD這種三段式的風(fēng)格來組織代碼受益良多。例如:
void should_be_unlocked_when_insert_coin_given_a_entrance_machine_with_locked_state() { EntranceMachine entranceMachine = new EntranceMachine(EntranceMachineState.LOCKED); String result = entranceMachine.execute(Action.INSERT_COIN); assertThat(result).isEqualsTo("opened"); assertThat(EntranceMachineState).isEqualsTo(entranceMachineState.UNLOCKED); }
我們可以清晰的知道哪行代碼在描述上下文,哪幾行代碼在描述測試意圖,哪幾行代碼在描述測試結(jié)果驗(yàn)證。
BDD的風(fēng)格能夠幫助團(tuán)隊(duì)將測試代碼維護(hù)的較為清晰。AssertJ提供了BDD風(fēng)格的斷言方式。使用then()語法。例如:
@Test void should_be_unlocked_when_insert_coin_given_a_entrance_machine_with_locked_state() { EntranceMachine entranceMachine = new EntranceMachine(EntranceMachineState.LOCKED); String result = entranceMachine.execute(Action.INSERT_COIN); then(result).isEqualsTo("opened"); then(EntranceMachineState).isEqualsTo(entranceMachineState.UNLOCKED); }
斷言變化不大。但是真正仔細(xì)讀的時(shí)候,會發(fā)現(xiàn)使用then()還是簡單那么一點(diǎn)點(diǎn)的。
我們常用的Mock工具M(jìn)ockito,也提供了BDD風(fēng)格的斷言:then(), should(), and()。
import static org.mockito.BDDMockito.then; import static org.assertj.core.api.BDDAssertions.and; import static org.mockito.Mockito.mock; import static org.mockito.Mockito.times; @SuppressWarnings("static-access") @Test public void bdd_assertions_with_bdd_mockito() { Person person = mock(Person.class) person.ride(bike); person.ride(bike); then(person).should(times(2)).ride(bike); and.then(person.hasBike()).isTrue(); }
所以日常開發(fā)中,我會首先選擇then(),其次會選擇assertThat()。
除了以上兩種斷言風(fēng)格,流式斷言讓代碼更清晰,斷言重復(fù)內(nèi)容更少
當(dāng)我們需要為某個結(jié)果測試多個測試點(diǎn)時(shí),如果為每個測試點(diǎn)都組織一次相同的上下文,那么重復(fù)代碼太多。帶來的價(jià)值就是那么一點(diǎn)點(diǎn)區(qū)別,所以在測試力度上我們可以根據(jù)經(jīng)驗(yàn)來在開發(fā)工程中動態(tài)調(diào)整。
下面據(jù)一個例子,當(dāng)我們需要驗(yàn)證有一個查詢方法返回的List的結(jié)果時(shí),不單單要驗(yàn)證List中元素的數(shù)量,還要驗(yàn)證元素是否時(shí)期望的順序。那么流式寫法會縮減一部分重復(fù)的斷言代碼。
then(users).hasSize(3) .containsExactlyInAnyOrder( firstUser, secondUser, thirdUser);
上面是日常工作中經(jīng)常使用到的斷言技巧,你的怎么選擇的呢?那種風(fēng)格無所謂能工作就行?
參考
以上就是本文的全部內(nèi)容,希望對大家的學(xué)習(xí)有所幫助,也希望大家多多支持腳本之家。
相關(guān)文章
哈希表在算法題目中的實(shí)際應(yīng)用詳解(Java)
散列表(Hash?table,也叫哈希表)是根據(jù)關(guān)鍵碼值(Key?value)而直接進(jìn)行訪問的數(shù)據(jù)結(jié)構(gòu),下面這篇文章主要給大家介紹了關(guān)于哈希表在算法題目中的實(shí)際應(yīng)用,文中介紹的方法是Java,需要的朋友可以參考下2024-03-03java并發(fā)高的情況下用ThreadLocalRandom來生成隨機(jī)數(shù)
如果我們想要生成一個隨機(jī)數(shù),通常會使用Random類。但是在并發(fā)情況下Random生成隨機(jī)數(shù)的性能并不是很理想,本文主要介紹了java并發(fā)高的情況下用ThreadLocalRandom來生成隨機(jī)數(shù),感興趣的可以了解一下2022-05-05Java數(shù)據(jù)結(jié)構(gòu)之?dāng)?shù)組(動力節(jié)點(diǎn)之Java學(xué)院整理)
這篇文章主要介紹了Java數(shù)據(jù)結(jié)構(gòu)之?dāng)?shù)組(動力節(jié)點(diǎn)之Java學(xué)院整理)的相關(guān)資料,包括創(chuàng)建和內(nèi)存分配,數(shù)組封裝后的使用等,需要的朋友參考下吧2017-04-04Spring中的@Conditional注解實(shí)現(xiàn)分析
這篇文章主要介紹了Spring中的@Conditional注解實(shí)現(xiàn)分析, @Conditional是Spring 4出現(xiàn)的注解,但是真正露出價(jià)值的是Spring Boot的擴(kuò)展@ConditionalOnBean等,需要的朋友可以參考下2023-12-12解決IDEA和CMD中java命令提示錯誤: 找不到或無法加載主類的問題
這篇文章主要介紹了解決IDEA和CMD中java命令提示錯誤: 找不到或無法加載主類的問題,本文給大家介紹的非常詳細(xì),對大家的學(xué)習(xí)或工作具有一定的參考借鑒價(jià)值,需要的朋友可以參考下2020-09-09