翻看之前的文章才發現，最近一次記錄持續集成竟然是3年前，并且只記錄了兩篇，實在是慚愧。不過，持續集成的這團火焰卻始終在心中燃燒，希望這次的開始可以有些突破。
測試是持續集成的基石，沒有測試的集成基本上是毫無意義的。如何寫好測試就是橫亙在我面前的第一個問題。那就從數據訪問層開始吧。說起來可笑，從3年前第一次準備做持續集成式，就開始考慮測試數據訪問層的一些問題：
難道我要在測試服務器上裝一個MySQL？
數據庫結構發生了變化怎么辦？
怎么樣才能消除測試間的依賴？
測試數據怎么管理？何況測試數據間還有那么多的邏輯？
結果如何驗證？
……
這些問題在我腦?？M繞很久，《一代宗師》里說“寧在一思進，莫在一思停”，及時想破腦袋，不如直接實踐。那就一個個問題來。
在繼續之前，先交代一下當前程序的架構，很經典的Spring + Spring Data + Hibernate + MySQL，所以下面的解決方案都是基于這個架構。另外，程序是通過Maven構建。
一、用內存數據庫替代MySQL
我選擇了HSQLDB，官網上有很多示例可以參考。HSQLDB提供幾種不同的使用模式，這里只選用內存模式。Spring通過<jdbc：embedded-database>標簽提供對了嵌入式數據庫的支持，在applicationContext-test.xml中對數據源的配置十分簡單：
| <jdbc:embedded-database id="dataSource" type="HSQL"/> |
HSQL不需要安裝，在pom.xml將jar包作為依賴引入即可：
<dependency>
<groupId>org.hsqldb</groupId>
<artifactId>hsqldb</artifactId>
<version>2.2.8</version>
<scope>test</scope>
</dependency> |
二、數據庫結構的維護
在項目的開發過程中，一直使用flyway維護數據庫結構變化。雖然Spring也通過<jdbc：initialize-database>提供了執行SQL的機會，但是經過測試發現并且不能完成flyway完成的任務。這個就開始思考：是否一定要選用flyway，并且通過SQL來控制結構改變？flyway主要是參考了ruby的db migration機制，每次修改都是上一次版本的基礎進行的，從而不會影響正在運行的邏輯?？墒窃陂_發階段并沒有必要使用flyway來控制，并且對SQL的維護也是要花費精力。于是就把目光轉向了Hibernate對DDL的支持，便有了下面的配置：
<!-- Jpa Entity Manager 配置 -->
<bean id="entityManagerFactory"
class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
<property name="dataSource" ref="dataSource" />
<property name="jpaVendorAdapter" ref="hibernateJpaVendorAdapter"></property>
<property name="packagesToScan" value="com.noyaxe.myapp" />
<property name="jpaProperties">
<props>
<!-- 命名規則 My_NAME->MyName -->
<prop key="hibernate.ejb.naming_strategy">org.hibernate.cfg.ImprovedNamingStrategy</prop>
<prop key="hibernate.show.sql">true</prop>
<prop key="hibernate.hbm2ddl.auto">update</prop>
</props>
</property>
</bean> |
可是對于Hibernate的DDL支持，我還是心存疑慮：1. 如果數據庫中已經存在數據，那么字段類型改變會如何處理？2. 如何才能更好維護DDL的變化？
?。ùm）