模板
教程
環境
性能
功能
管理
持續集成之路——數據訪問層的單元測試
翻看之前的文章才發現，最近一次記錄持續集成竟然是3年前，并且只記錄了兩篇，實在是慚愧。不過，持續集成的這團火焰卻始終在心中燃燒，希望這次的開始可以有些突破。
測試是持續集成的基石，沒有測試的集成基本上是毫無意義的。如何寫好測試就是橫亙在我面前的第一個問題。那就從數據訪問層開始吧。說起來可笑，從3年前第一次準備做持續集成式，就開始考慮測試數據訪問層的一些問題：
數據庫結構發生了變化怎么辦?
怎么樣才能消除測試間的依賴?
測試數據怎么管理?何況測試數據間還有那么多的邏輯?
結果如何驗證?
……
這些問題在我腦?？M繞很久，《一代宗師》里說“寧在一思進，莫在一思停”，及時想破腦袋，不如直接實踐。那就一個個問題來。
在繼續之前，先交代一下當前程序的架構，很經典的Spring + Spring Data + Hibernate + MySQL，所以下面的解決方案都是基于這個架構。另外，程序是通過Maven構建。
一、用內存數據庫替代MySQL
我選擇了HSQLDB，官網上有很多示例可以參考。HSQLDB提供幾種不同的使用模式，這里只選用內存模式。Spring通過標簽提供對了嵌入式數據庫的支持，在applicationContext-test.xml中對數據源的配置十分簡單：
[html] view plaincopyprint?
HSQL不需要安裝，在pom.xml將jar包作為依賴引入即可：
[html] view plaincopyprint?
org.hsqldb
hsqldb
2.2.8
test
org.hsqldb
hsqldb
2.2.8
test
二、數據庫結構的維護
在項目的開發過程中，一直使用flyway維護數據庫結構變化。雖然Spring也通過提供了執行SQL的機會，但是經過測試發現并且不能完成flyway完成的任務。這個就開始思考：是否一定要選用flyway，并且通過SQL來控制結構改變?flyway主要是參考了ruby的db migration機制，每次修改都是上一次版本的基礎進行的，從而不會影響正在運行的邏輯?？墒窃?a href='http://www.anti-gravitydesign.com/ceshi/ruanjianceshikaifajishu/' target='_blank'>開發階段并沒有必要使用flyway來控制，并且對SQL的維護也是要花費精力。于是就把目光轉向了Hibernate對DDL的支持，便有了下面的配置：
[html] view plaincopyprint?
class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
org.hibernate.cfg.ImprovedNamingStrategy
true
update
class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
org.hibernate.cfg.ImprovedNamingStrategy
true
update
可是對于Hibernate的DDL支持，我還是心存疑慮：1. 如果數據庫中已經存在數據，那么字段類型改變會如何處理?2. 如何才能更好維護DDL的變化?
(待續)
補記：
首先十分感謝csfreebird的指教，讓我停下來思考為什么要選用HSQLDB背后的問題。下面幾篇文章供大家參考，尤其是最后一篇文章值得仔細思考：
Testing Databases with JUnit and Hibernate Part 1: One to Rule them
Database unit testing with DBUnit, Spring and TestNG
Basic Mistakes in Database Testing
原文轉自：http://blog.csdn.net/mydeman/article/details/9327923
