使用 Spring Framework 時(shí)常犯的十大錯(cuò)誤
Spring 可以說(shuō)是最流行的 Java 框架之一，也是一只需要馴服的強(qiáng)大野獸。雖然它的基本概念相當(dāng)容易掌握，但成為一名強(qiáng)大的 Spring 開發(fā)者仍需要很多時(shí)間和努力。
在本文中，我們將介紹 Spring 中一些常見的錯(cuò)誤，特別是面向 Web 應(yīng)用程序和 Spring Boot。正如 Spring Boot 官網(wǎng) 所說(shuō)，Spring Boot 對(duì)應(yīng)該如何構(gòu)建 Production-Ready 的應(yīng)用保持著 相當(dāng)固執(zhí)的觀點(diǎn)，本文將嘗試模仿這種觀點(diǎn)，并提供一些技巧的概述，這些技巧將很好地融入標(biāo)準(zhǔn) Spring Boot 的 web 應(yīng)用程序開發(fā)中去。
如果你對(duì) Spring Boot 還不是很熟悉，但仍想嘗試下接下來(lái)提到的一些內(nèi)容，我也為本文創(chuàng)建了一個(gè) GitHub 倉(cāng)庫(kù)。如果你在閱讀過(guò)程中感到困惑，我建議把代碼 clone 下來(lái)，并在本地電腦上使用這些代碼。
1. 常見錯(cuò)誤一：太過(guò)關(guān)注底層
我們正在解決這個(gè)常見錯(cuò)誤，是因?yàn)?“非我所創(chuàng)” 綜合癥在軟件開發(fā)領(lǐng)域很是常見。癥狀包括經(jīng)常重寫一些常見的代碼，很多開發(fā)人員都有這種癥狀。
雖然理解特定庫(kù)的內(nèi)部結(jié)構(gòu)及其實(shí)現(xiàn)，在很大程度上是好的并且很有必要的(也可以是一個(gè)很好的學(xué)習(xí)過(guò)程)，但作為軟件工程師，不斷地處理相同的底層實(shí)現(xiàn)細(xì)節(jié)對(duì)個(gè)人的開發(fā)生涯是有害的。像 Spring 這種抽象框架的存在是有原因的，它將你從重復(fù)地手工勞作中解放出來(lái)，并允許你專注于更高層次的細(xì)節(jié) —— 領(lǐng)域?qū)ο蠛蜆I(yè)務(wù)邏輯。
因此，接受抽象。下次面對(duì)特定問(wèn)題時(shí)，首先進(jìn)行快速搜索，確定解決該問(wèn)題的庫(kù)是否已被集成到 Spring 中;現(xiàn)在，你可能找到一個(gè)合適的現(xiàn)成解決方案。比如，一個(gè)很有用的庫(kù)，在本文的其他部分，我將在示例中使用 Project Lombok 注解。Lombok 被用作樣板代碼生成器，希望懶惰的開發(fā)人員在熟悉這個(gè)庫(kù)時(shí)不會(huì)遇到問(wèn)題。舉個(gè)例子，看看使用 Lombok 的 “標(biāo)準(zhǔn) Java Bean” 是什么樣子的：
- @Getter
- @Setter
- @NoArgsConstructor
- public class Bean implements Serializable {
- int firstBeanProperty;
- String secondBeanProperty;
- }
如你所想，上述代碼被編譯為：
- public class Bean implements Serializable {
- private int firstBeanProperty;
- private String secondBeanProperty;
- public int getFirstBeanProperty() {
- return this.firstBeanProperty;
- }
- public String getSecondBeanProperty() {
- return this.secondBeanProperty;
- }
- public void setFirstBeanProperty(int firstBeanProperty) {
- this.firstBeanProperty = firstBeanProperty;
- }
- public void setSecondBeanProperty(String secondBeanProperty) {
- this.secondBeanProperty = secondBeanProperty;
- }
- public Bean() {
- }
- }
但是，請(qǐng)注意，如果你打算在 IDE 中使用 Lombok，很可能需要安裝一個(gè)插件，可在 此處 找到 Intellij IDEA 版本的插件。
2. 常見錯(cuò)誤二：內(nèi)部結(jié)構(gòu) “泄露”
公開你的內(nèi)部結(jié)構(gòu)，從來(lái)都不是一個(gè)好主意，因?yàn)樗诜?wù)設(shè)計(jì)中造成了不靈活性，從而促進(jìn)了不好的編碼實(shí)踐。“泄露” 的內(nèi)部機(jī)制表現(xiàn)為使數(shù)據(jù)庫(kù)結(jié)構(gòu)可以從某些 API 端點(diǎn)訪問(wèn)。例如，下面的 POJO(“Plain Old Java Object”)類表示數(shù)據(jù)庫(kù)中的一個(gè)表：
- @Entity
- @NoArgsConstructor
- @Getter
- public class TopTalentEntity {
- @Id
- @GeneratedValue
- private Integer id;
- @Column
- private String name;
- public TopTalentEntity(String name) {
- this.name = name;
- }
- }
假設(shè)，存在一個(gè)端點(diǎn)，他需要訪問(wèn) TopTalentEntity 數(shù)據(jù)。返回 TopTalentEntity 實(shí)例可能很誘人，但更靈活的解決方案是創(chuàng)建一個(gè)新的類來(lái)表示 API 端點(diǎn)上的 TopTalentEntity 數(shù)據(jù)。
- @AllArgsConstructor
- @NoArgsConstructor
- @Getter
- public class TopTalentData {
- private String name;
- }
這樣，對(duì)數(shù)據(jù)庫(kù)后端進(jìn)行更改將不需要在服務(wù)層進(jìn)行任何額外的更改。考慮下，在 TopTalentEntity 中添加一個(gè) “password” 字段來(lái)存儲(chǔ)數(shù)據(jù)庫(kù)中用戶密碼的 Hash 值 —— 如果沒(méi)有 TopTalentData 之類的連接器，忘記更改服務(wù)前端，將會(huì)意外地暴露一些不必要的秘密信息。
3. 常見錯(cuò)誤三：缺乏關(guān)注點(diǎn)分離
隨著程序規(guī)模的增長(zhǎng)，逐漸地，代碼組織成為一個(gè)越來(lái)越重要的問(wèn)題。諷刺的是，大多數(shù)好的軟件工程原則開始在規(guī)模上崩潰 —— 特別是在沒(méi)有太多考慮程序體系結(jié)構(gòu)設(shè)計(jì)的情況下。開發(fā)人員最常犯的一個(gè)錯(cuò)誤就是混淆代碼關(guān)注點(diǎn)，這很容易做到!
通常，打破 關(guān)注點(diǎn)分離 的是將新功能簡(jiǎn)單地 “倒” 在現(xiàn)有類中。當(dāng)然，這是一個(gè)很好的短期解決方案(對(duì)于初學(xué)者來(lái)說(shuō)，它需要更少的輸入)，但它也不可避免地會(huì)在將來(lái)成為一個(gè)問(wèn)題，無(wú)論是在測(cè)試期間、維護(hù)期間還是介于兩者之間。考慮下下面的控制器，它將從數(shù)據(jù)庫(kù)返回TopTalentData。
- @RestController
- public class TopTalentController {
- private final TopTalentRepository topTalentRepository;
- @RequestMapping("/toptal/get")
- public List<TopTalentData> getTopTalent() {
- return topTalentRepository.findAll()
- .stream()
- .map(this::entityToData)
- .collect(Collectors.toList());
- }
- private TopTalentData entityToData(TopTalentEntity topTalentEntity) {
- return new TopTalentData(topTalentEntity.getName());
- }
- }
起初，這段代碼似乎沒(méi)什么特別的問(wèn)題;它提供了一個(gè)從 TopTalentEntity 實(shí)例檢索出來(lái)的TopTalentData 的 List。然而，仔細(xì)觀察下，我們可以看到 TopTalentController 實(shí)際上在此做了些事情;也就是說(shuō)，它將請(qǐng)求映射到特定端點(diǎn)，從數(shù)據(jù)庫(kù)檢索數(shù)據(jù)，并將從 TopTalentRepository 接收的實(shí)體轉(zhuǎn)換為另一種格式。一個(gè)“更干凈” 的解決方案是將這些關(guān)注點(diǎn)分離到他們自己的類中。看起來(lái)可能是這個(gè)樣子的：
- @RestController
- @RequestMapping("/toptal")
- @AllArgsConstructor
- public class TopTalentController {
- private final TopTalentService topTalentService;
- @RequestMapping("/get")
- public List<TopTalentData> getTopTalent() {
- return topTalentService.getTopTalent();
- }
- }
- @AllArgsConstructor
- @Service
- public class TopTalentService {
- private final TopTalentRepository topTalentRepository;
- private final TopTalentEntityConverter topTalentEntityConverter;
- public List<TopTalentData> getTopTalent() {
- return topTalentRepository.findAll()
- .stream()
- .map(topTalentEntityConverter::toResponse)
- .collect(Collectors.toList());
- }
- }
- @Component
- public class TopTalentEntityConverter {
- public TopTalentData toResponse(TopTalentEntity topTalentEntity) {
- return new TopTalentData(topTalentEntity.getName());
- }
- }
這種層次結(jié)構(gòu)的另一個(gè)優(yōu)點(diǎn)是，它允許我們通過(guò)檢查類名來(lái)確定將功能駐留在何處。此外，在測(cè)試期間，如果需要，我們可以很容易地用模擬實(shí)現(xiàn)來(lái)替換任何類。
4. 常見錯(cuò)誤四：缺乏異常處理或處理不當(dāng)
一致性的主題并非是 Spring(或 Java)所獨(dú)有的，但仍然是處理 Spring 項(xiàng)目時(shí)需要考慮的一個(gè)重要方面。雖然編碼風(fēng)格可能存在爭(zhēng)議(通常團(tuán)隊(duì)或整個(gè)公司內(nèi)部已達(dá)成一致)，但擁有一個(gè)共同的標(biāo)準(zhǔn)最終會(huì)極大地提高生產(chǎn)力。對(duì)多人團(tuán)隊(duì)尤為如此;一致性允許交流發(fā)生，而不需要花費(fèi)很多資源在手把手交接上，也不需要就不同類的職責(zé)提供冗長(zhǎng)的解釋。
考慮一個(gè)包含各種配置文件、服務(wù)和控制器的 Spring 項(xiàng)目。在命名時(shí)保持語(yǔ)義上的一致性，可以創(chuàng)建一個(gè)易于搜索的結(jié)構(gòu)，任何新的開發(fā)人員都可以按照自己的方式管理代碼;例如，將 Config 后綴添加到配置類，服務(wù)層以 Service 結(jié)尾，以及控制器用 Controller 結(jié)尾。
與一致性主題密切相關(guān)，服務(wù)器端的錯(cuò)誤處理值得特別強(qiáng)調(diào)。如果你曾經(jīng)不得不處理編寫很差的 API 的異常響應(yīng)，那你可能知道原因 —— 正確解析異常會(huì)是一件痛苦的事情，而確定這些異常最初發(fā)生的原因則更為痛苦。
作為一名 API 開發(fā)者，理想情況下你希望覆蓋所有面向用戶的端點(diǎn)，并將他們轉(zhuǎn)換為常見的錯(cuò)誤格式。這通常意味著有一個(gè)通用的錯(cuò)誤代碼和描述，而不是逃避解決問(wèn)題：a) 返回一個(gè) “500 Internal Server Error”信息。b) 直接返回異常的堆棧信息給用戶。(實(shí)際上，這些都應(yīng)該不惜一切代價(jià)地去避免，因?yàn)槌丝蛻舳穗y以處理以外，它還暴露了你的內(nèi)部信息)。
例如，常見錯(cuò)誤響應(yīng)格式可能長(zhǎng)這樣：
- @Value
- public class ErrorResponse {
- private Integer errorCode;
- private String errorMessage;
- }
與此類似的事情在大多數(shù)流行的 API 中也經(jīng)常遇到，由于可以容易且系統(tǒng)地記錄，效果往往很不錯(cuò)。將異常轉(zhuǎn)換為這種格式可以通過(guò)向方法提供 @ExceptionHandler 注解來(lái)完成(注解案例可見于第六章)。
5. 常見錯(cuò)誤五：多線程處理不當(dāng)
不管是桌面應(yīng)用還是 Web 應(yīng)用，無(wú)論是 Spring 還是 No Spring，多線程都是很難破解的。由并行執(zhí)行程序所引起的問(wèn)題是令人毛骨悚然且難以捉摸的，而且常常難以調(diào)試 —— 實(shí)際上，由于問(wèn)題的本質(zhì)，一旦你意識(shí)到你正在處理一個(gè)并行執(zhí)行問(wèn)題，你可能就不得不完全放棄調(diào)試器了，并 “手動(dòng)” 檢查代碼，直到找到根本上的錯(cuò)誤原因。不幸的是，這類問(wèn)題并沒(méi)有千篇一律的解決方案;根據(jù)具體場(chǎng)景來(lái)評(píng)估情況，然后從你認(rèn)為最好的角度來(lái)解決問(wèn)題。
當(dāng)然，理想情況下，你也希望完全避免多線程錯(cuò)誤。同樣，不存在那種一刀切的方法，但這有一些調(diào)試和防止多線程錯(cuò)誤的實(shí)際考慮因素：
5.1. 避免全局狀態(tài)
首先，牢記 “全局狀態(tài)” 問(wèn)題。如果你正創(chuàng)建一個(gè)多線程應(yīng)用，那么應(yīng)該密切關(guān)注任何可能全局修改的內(nèi)容，如果可能的話，將他們?nèi)縿h掉。如果某個(gè)全局變量有必須保持可修改的原因，請(qǐng)仔細(xì)使用 synchronization，并對(duì)程序性能進(jìn)行跟蹤，以確定沒(méi)有因?yàn)樾乱氲牡却龝r(shí)間而導(dǎo)致系統(tǒng)性能降低。
5.2. 避免可變性
這點(diǎn)直接來(lái)自于 函數(shù)式編程，并且適用于 OOP，聲明應(yīng)該避免類和狀態(tài)的改變。簡(jiǎn)而言之，這意味著放棄 setter 方法，并在所有模型類上擁有私有的 final 字段。它們的值唯一發(fā)生變化的時(shí)間是在構(gòu)造期間。這樣，你可以確定不會(huì)出現(xiàn)爭(zhēng)用問(wèn)題，且訪問(wèn)對(duì)象屬性將始終提供正確的值。
5.3. 記錄關(guān)鍵數(shù)據(jù)
評(píng)估你的程序可能會(huì)在何處發(fā)生異常，并預(yù)先記錄所有關(guān)鍵數(shù)據(jù)。如果發(fā)生錯(cuò)誤，你將很高興可以得到信息說(shuō)明收到了哪些請(qǐng)求，并可更好地了解你的應(yīng)用程序?yàn)槭裁磿?huì)出現(xiàn)錯(cuò)誤。需要再次注意的是，日志記錄引入了額外的文件 I/O，可能會(huì)嚴(yán)重影響應(yīng)用的性能，因此請(qǐng)不要濫用日志。
5.4. 復(fù)用現(xiàn)存實(shí)現(xiàn)
每當(dāng)你需要?jiǎng)?chuàng)建自己的線程時(shí)(例如：向不同的服務(wù)發(fā)出異步請(qǐng)求)，復(fù)用現(xiàn)有的安全實(shí)現(xiàn)來(lái)代替創(chuàng)建自己的解決方案。這在很大程度上意味著要使用 ExecutorServices 和 Java 8 簡(jiǎn)潔的函數(shù)式 [CompletableFutures](http://www.nurkiewicz.com/2013/05/java-8-definition -guide-to - .html) 來(lái)創(chuàng)建線程。Spring 還允許通過(guò) [DeferredResult](http://docs.spring.io/springing-framework/docs/4.0.x/springing-frame-reference/html/mvc.html # mvc.ann-async) 類來(lái)進(jìn)行異步請(qǐng)求處理。
6. 常見錯(cuò)誤六：不使用基于注解的驗(yàn)證
假設(shè)我們之前的 TopTalent 服務(wù)需要一個(gè)端點(diǎn)來(lái)添加新的 TopTalent。此外，假設(shè)基于某些原因，每個(gè)新名詞都需要為 10 個(gè)字符長(zhǎng)度。執(zhí)行此操作的一種方法可能如下：
- @RequestMapping("/put")
- public void addTopTalent(@RequestBody TopTalentData topTalentData) {
- boolean nameNonExistentOrHasInvalidLength =
- Optional.ofNullable(topTalentData)
- .map(TopTalentData::getName)
- .map(name -> name.length() == 10)
- .orElse(true);
- if (nameNonExistentOrInvalidLength) {
- // throw some exception
- }
- topTalentService.addTopTalent(topTalentData);
- }
然而，上面的方法(除了構(gòu)造很差以外)并不是一個(gè)真正 “干凈” 的解決辦法。我們正檢查不止一種類型的有效性(即 TopTalentData 不得為空，TopTalentData.name 不得為空，且 TopTalentData.name 為 10 個(gè)字符長(zhǎng)度)，以及在數(shù)據(jù)無(wú)效時(shí)拋出異常。
通過(guò)在 Spring 中集成 [Hibernate validator](http://hibernate nate.org/validator/)，數(shù)據(jù)校驗(yàn)可以更干凈地進(jìn)行。讓我們首先重構(gòu) addTopTalent 方法來(lái)支持驗(yàn)證：
- @RequestMapping("/put")
- public void addTopTalent(@Valid @NotNull @RequestBody TopTalentData topTalentData) {
- topTalentService.addTopTalent(topTalentData);
- }
- @ExceptionHandler
- @ResponseStatus(HttpStatus.BAD_REQUEST)
- public ErrorResponse handleInvalidTopTalentDataException(MethodArgumentNotValidException methodArgumentNotValidException) {
- // handle validation exception
- }
此外，我們還必須指出我們想要在 TopTalentData 類中驗(yàn)證什么屬性：
- public class TopTalentData {
- @Length(min = 10, max = 10)
- @NotNull
- private String name;
- }
現(xiàn)在，Spring 將在調(diào)用方法之前攔截其請(qǐng)求并對(duì)參數(shù)進(jìn)行驗(yàn)證 —— 無(wú)需使用額外的手工測(cè)試。
另一種實(shí)現(xiàn)相同功能的方法是創(chuàng)建我們自己的注解。雖然你通常只在需要超出 Hibernate的內(nèi)置約束集 時(shí)才使用自定義注解，本例中，我們假設(shè) @Length 不存在。你可以創(chuàng)建兩個(gè)額外的類來(lái)驗(yàn)證字符串長(zhǎng)度，一個(gè)用于驗(yàn)證，一個(gè)用于對(duì)屬性進(jìn)行注解：
- @Target({ElementType.METHOD, ElementType.FIELD, ElementType.PARAMETER})
- @Retention(RetentionPolicy.RUNTIME)
- @Documented
- @Constraint(validatedBy = { MyAnnotationValidator.class })
- public @interface MyAnnotation {
- String message() default "String length does not match expected";
- Class<?>[] groups() default {};
- Class<? extends Payload>[] payload() default {};
- int value();
- }
- @Component
- public class MyAnnotationValidator implements ConstraintValidator<MyAnnotation, String> {
- private int expectedLength;
- @Override
- public void initialize(MyAnnotation myAnnotation) {
- this.expectedLength = myAnnotation.value();
- }
- @Override
- public boolean isValid(String s, ConstraintValidatorContext constraintValidatorContext) {
- return s == null || s.length() == this.expectedLength;
- }
- }
請(qǐng)注意，這些情況下，關(guān)注點(diǎn)分離的最佳實(shí)踐要求在屬性為 null 時(shí)，將其標(biāo)記為有效(isValid 方法中的 s == null)，如果這是屬性的附加要求，則使用 @NotNull 注解。
- public class TopTalentData {
- @MyAnnotation(value = 10)
- @NotNull
- private String name;
- }
7. 常見錯(cuò)誤七：(依舊)使用基于xml的配置
雖然之前版本的 Spring 需要 XML，但如今大部分配置均可通過(guò) Java 代碼或注解來(lái)完成;XML 配置只是作為附加的不必要的樣板代碼。
本文(及其附帶的 GitHub 倉(cāng)庫(kù))均使用注解來(lái)配置 Spring，Spring 知道應(yīng)該連接哪些 Bean，因?yàn)榇龗呙璧捻敿?jí)包目錄已在 @SpringBootApplication 復(fù)合注解中做了聲明，如下所示：
- @SpringBootApplication
- public class Application {
- public static void main(String[] args) {
- SpringApplication.run(Application.class, args);
- }
- }
復(fù)合注解(可通過(guò) [Spring 文檔](http://docs.spring.io/autorepo/docs/springing-boot/current/reference/html/using-boot -using-springbootapplication- annot.html) 了解更多信息)只是向 Spring 提示應(yīng)該掃描哪些包來(lái)檢索 Bean。在我們的案例中，這意味著這個(gè)頂級(jí)包 (co.kukurin)將用于檢索：
- @Component (TopTalentConverter, MyAnnotationValidator)
- @RestController (TopTalentController)
- @Repository (TopTalentRepository)
- @Service (TopTalentService) 類
如果我們有任何額外的 @Configuration 注解類，它們也會(huì)檢查基于 Java 的配置。
8. 常見錯(cuò)誤八：忽略 profile
在服務(wù)端開發(fā)中，經(jīng)常遇到的一個(gè)問(wèn)題是區(qū)分不同的配置類型，通常是生產(chǎn)配置和開發(fā)配置。在每次從測(cè)試切換到部署應(yīng)用程序時(shí)，不要手動(dòng)替換各種配置項(xiàng)，更有效的方法是使用 profile。
考慮這么一種情況：你正在使用內(nèi)存數(shù)據(jù)庫(kù)進(jìn)行本地開發(fā)，而在生產(chǎn)環(huán)境中使用 MySQL 數(shù)據(jù)庫(kù)。本質(zhì)上，這意味著你需要使用不同的 URL 和 (希望如此) 不同的憑證來(lái)訪問(wèn)這兩者。讓我們看看可以如何做到這兩個(gè)不同的配置文件：
8.1. APPLICATION.YAML 文件
- # set default profile to 'dev'
- spring.profiles.active: dev
- # production database details
- spring.datasource.url: 'jdbc:mysql://localhost:3306/toptal'
- spring.datasource.username: root
- spring.datasource.password:
8.2. APPLICATION-DEV.YAML 文件
- spring.datasource.url: 'jdbc:h2:mem:'
- spring.datasource.platform: h2
假設(shè)你不希望在修改代碼時(shí)意外地對(duì)生產(chǎn)數(shù)據(jù)庫(kù)進(jìn)行任何操作，因此將默認(rèn)配置文件設(shè)為 dev 是很有意義的。然后，在服務(wù)器上，你可以通過(guò)提供 -Dspring.profiles.active=prod 參數(shù)給 JVM 來(lái)手動(dòng)覆蓋配置文件。另外，還可將操作系統(tǒng)的環(huán)境變量設(shè)置為所需的默認(rèn) profile。
9. 常見錯(cuò)誤九：無(wú)法接受依賴項(xiàng)注入
正確使用 Spring 的依賴注入意味著允許其通過(guò)掃描所有必須的配置類來(lái)將所有對(duì)象連接在一起;這對(duì)于解耦關(guān)系非常有用，也使測(cè)試變得更為容易，而不是通過(guò)類之間的緊耦合來(lái)做這樣的事情：
- public class TopTalentController {
- private final TopTalentService topTalentService;
- public TopTalentController() {
- this.topTalentService = new TopTalentService();
- }
- }
我們讓 Spring 為我們做連接：
- public class TopTalentController {
- private final TopTalentService topTalentService;
- public TopTalentController(TopTalentService topTalentService) {
- this.topTalentService = topTalentService;
- }
- }
Misko Hevery 的 Google talk 深入解釋了依賴注入的 “為什么”，所以，讓我們看看它在實(shí)踐中是如何使用的。在關(guān)注點(diǎn)分離(常見錯(cuò)誤 #3)一節(jié)中，我們創(chuàng)建了一個(gè)服務(wù)和控制器類。假設(shè)我們想在 TopTalentService 行為正確的前提下測(cè)試控制器。我們可以通過(guò)提供一個(gè)單獨(dú)的配置類來(lái)插入一個(gè)模擬對(duì)象來(lái)代替實(shí)際的服務(wù)實(shí)現(xiàn)：
- @Configuration
- public class SampleUnitTestConfig {
- @Bean
- public TopTalentService topTalentService() {
- TopTalentService topTalentService = Mockito.mock(TopTalentService.class);
- Mockito.when(topTalentService.getTopTalent()).thenReturn(
- Stream.of("Mary", "Joel").map(TopTalentData::new).collect(Collectors.toList()));
- return topTalentService;
- }
- }
然后，我們可以通過(guò)告訴 Spring 使用 SampleUnitTestConfig 作為它的配置類來(lái)注入模擬對(duì)象：
- @ContextConfiguration(classes = { SampleUnitTestConfig.class })
之后，我們就可以使用上下文配置將 Bean 注入到單元測(cè)試中。
10. 常見錯(cuò)誤十：缺乏測(cè)試，或測(cè)試不當(dāng)
盡管單元測(cè)試的概念已經(jīng)存在很長(zhǎng)時(shí)間了，但很多開發(fā)人員似乎要么 “忘記” 做這件事(特別是如果它不是 “必需” 的時(shí)候)，要么只是在事后把它添加進(jìn)來(lái)。這顯然是不可取的，因?yàn)闇y(cè)試不僅應(yīng)該驗(yàn)證代碼的正確性，還應(yīng)該作為程序在不同場(chǎng)景下應(yīng)如何表現(xiàn)的文檔。
在測(cè)試 Web 服務(wù)時(shí)，很少只進(jìn)行 “純” 單元測(cè)試，因?yàn)橥ㄟ^(guò) HTTP 進(jìn)行通信通常需要調(diào)用 Spring 的 DispatcherServlet，并查看當(dāng)收到一個(gè)實(shí)際的 HttpServletRequest 時(shí)會(huì)發(fā)生什么(使它成為一個(gè) “集成” 測(cè)試，處理驗(yàn)證、序列化等)。REST Assured，一個(gè)用于簡(jiǎn)化測(cè)試REST服務(wù)的 Java DSL，在 MockMVC 之上，已經(jīng)被證明提供了一個(gè)非常優(yōu)雅的解決方案。考慮以下帶有依賴項(xiàng)注入的代碼片段：
- @RunWith(SpringJUnit4ClassRunner.class)
- @ContextConfiguration(classes = {
- Application.class,
- SampleUnitTestConfig.class
- })
- public class RestAssuredTestDemonstration {
- @Autowired
- private TopTalentController topTalentController;
- @Test
- public void shouldGetMaryAndJoel() throws Exception {
- // given
- MockMvcRequestSpecification givenRestAssuredSpecification = RestAssuredMockMvc.given()
- .standaloneSetup(topTalentController);
- // when
- MockMvcResponse response = givenRestAssuredSpecification.when().get("/toptal/get");
- // then
- response.then().statusCode(200);
- response.then().body("name", hasItems("Mary", "Joel"));
- }
- }
SampleUnitTestConfig 類將 TopTalentService 的模擬實(shí)現(xiàn)連接到 TopTalentController中，而所有的其他類都是通過(guò)掃描應(yīng)用類所在包的下級(jí)包目錄來(lái)推斷出的標(biāo)準(zhǔn)配置。RestAssuredMockMvc 只是用來(lái)設(shè)置一個(gè)輕量級(jí)環(huán)境，并向 /toptal/get 端點(diǎn)發(fā)送一個(gè) GET 請(qǐng)求。
11. 成為 Spring 大師
Spring 是一個(gè)功能強(qiáng)大的框架，很容易上手，但需要一些投入和時(shí)間才可以完全掌握。長(zhǎng)遠(yuǎn)來(lái)看，花時(shí)間熟悉框架肯定會(huì)提高你的生產(chǎn)力，并最終助你寫出更干凈的代碼，成為更好的開發(fā)人員。
