領域驅動設計之單元測試最佳實踐(二)
一直以來,我試圖找到一種有效的單元測試模式,使得“單元測試”真正能夠在團隊中流行起來,讓單元測試不再是走過場,而是讓單元測試切切實實成爲提高代碼質量的途徑。
本文將描述一種以EF Code First模式實現的領域驅動項目實施單元測試的方案。
在描述這一方案之前,讓我們看看這一最佳實踐源於何種考慮和最終實現的目標:
1、以MVC項目爲例,如果將單元測試的重心放在如何測試一個Controller或Action將收效甚微,原因有二:
- 從原則上講Controller中不包含業務邏輯,理論上大部分代碼都是ViewModel和DTO之間的賦值或者Service的調用,對這樣的代碼編寫單元測試收效甚微,性價比極低。
- Controller的代碼對UI的依賴度很高,也就意味着Controller的代碼不夠穩定,這將迫使單元測試的變化頻率過高,容易給開發人員造成單元測試是一種負擔的心理。
基於這樣的原因,我將不建議人手緊張的團隊對Controller編寫單元測試。
2、一個軟件項目真正需要測試的重心是業務邏輯,對一個領域驅動項目來說,領域邏輯纔是重心。但是我們知道領域邏輯離不開數據的支撐,也就是說我們需要跟Repository打交道。
對於這樣的一個測試場景,大多數教程會提示你Mock Repository,從單元測試的角度來講,這樣的方案無疑是正確的,但是這樣的方案存在兩個問題:
- 實際經驗告訴我們這樣的測試不能真實的反應出代碼的問題,甚至出現單元測試是通過的,可是Debug起來卻有問題。原因在於我們忽略了數據庫部分,這一部分邏輯處於失控狀態。
- 需要Mock的數據太多,有時候爲了測試一個邏輯,Mock的代碼比測試還要多,給開發人員造成單元測試其實就是在玩Mock的錯誤認識。
所以我心目中理想的單元測試應該具備以下條件:
- 測試從Service->Repository->Domain一條線測試完畢,測試能夠準確反應出代碼是如何運行的。所以準確來講我這個方案應該叫“領域驅動設計之集成測試”。
- 儘量不Mock,包括讀取數據庫部分。
- 測試需要的數據應該是可複用的,對測試“註冊用戶”、“搜索用戶”這樣的業務邏輯應該能夠複用測試所提供的數據。
- 任何測試都可以獨立運行,同一個測試多次執行的效果應該是一致的,測試的執行速度儘可能快。
爲了能夠儘可能的貼近這一目標,我實現了一個很簡單的DDD案例用來做測試用,這一案例描述了兩個重要的領域模型:User領域模型描述了“註冊用戶”、“更改密碼”、“登錄”等邏輯;BookManageProcess領域模型描述了“借書”、“歸還圖書”等邏輯,你可以理解爲這是一個圖書館借書及還書的模型。
爲了能夠理解此測試方案,我將對該測試案例做一個簡單描述:
該案例基於EF Code First和Castle實現的一個DDD案例,這一測試方案也是爲DDD量身定製,並不適合於傳統的三層架構。
爲什麼說這一案例是一個領域驅動案例?
以“用戶註冊”這一功能爲例,我們來分析一下:
1、從UserService這一入口來看:
public class UserService : ApplicationService, IUserService { private readonly IUserRepository _userRepository; private readonly IEmailUniqueChecker _emailUniqueChecker; public UserService(IRepositoryContext context, IUserRepository userRepository,IEmailUniqueChecker emailUniqueChecker) : base(context) { _userRepository = userRepository; _emailUniqueChecker = emailUniqueChecker; } public Guid Register(UserModel userModel) { var user = User.Register(userModel,_emailUniqueChecker); _userRepository.Add(user); Context.Commit(); return user.Id; } }
Register()方法中幾乎只是對領域模型User.Register()方法的調用,其餘的代碼都可以忽略不計,這說明了這樣一個事實:Service層沒有任何業務邏輯,所有的邏輯都應該在Domain。
2、User領域模型中Register()方法的實現:
public partial class User { public static User Register(UserModel userModel, IEmailUniqueChecker emailUniqueChecker) { Contract.Requires(!userModel.Name.IsNullOrEmpty(), "invalid username"); if (emailUniqueChecker.IsExist(userModel.Email)) { throw new DuplicateEmailException("email already exist, please input another one"); } var password=new Password(userModel.Password); var user = new User() { Id = Guid.NewGuid(), Name = userModel.Name, Password = password.HashedPassword, Salt = password.Salt, Email = userModel.Email, RegisterDateTime = DateTime.Now, LastLoginDateTime = DateTime.Now }; return user; } }
首先這是一個Patial類,因爲另一部分描述屬性的內容被EF用來操作數據庫。這一方法主要存在兩個邏輯:
對Email的檢查,以及對password的加密處理,正如你所見:這些邏輯反應出了註冊一個用戶的實際邏輯是什麼,而這些邏輯全部都應該歸屬於Domain。
由於在Domain中無法進行依賴注入,所以我們從Service層通過方法傳入了IEmailUniqueChecker組件,具體實現如下:
public class EmailUniqueChecker:IEmailUniqueChecker { private readonly IUserRepository _userRepository; public EmailUniqueChecker(IUserRepository userRepository) { _userRepository = userRepository; } public bool IsExist(string email) { var user = _userRepository.Find(x => x.Email.ToLower() == email.ToLower()).FirstOrDefault(); return user != null; } }
而Password類測抽象了“密碼”的業務規則,同樣這一抽象應該屬於Domain,讓我們來看看他的部分實現:
public class Password { public byte[] HashedPassword { get; private set; } public byte[] Salt { get; } public Password(string password) { AssertPasswordMatchesPolicy(password); Salt = Guid.NewGuid().ToByteArray(); HashedPassword = HashPassword(salt: Salt, password: password); } private void AssertPasswordMatchesPolicy(string password) { if (password == null) { var error = Seq.Create("password can not be null"); throw new PasswordDoesNotMatchPolicyException(error); } var errors = new List<string>(); if (password.Trim().Length < 6) { errors.Add("password shorter than six characters"); } if (password.ToLower() == password) { errors.Add("password missing uppercase characters"); } if (password.ToUpper() == password) { errors.Add("password missing lowercase characters"); } if (errors.Any()) { throw new PasswordDoesNotMatchPolicyException(errors); } } }
如果不是由於Password類的存在,所有這些代碼都應該寫在User領域模型的Register()方法中。
繼續分析“用戶登錄”這一過程:
1、UserService中的入口:
public bool Login(string email, string password) { var user = _userRepository.Find(x => x.Email.ToLower() == email.ToLower()).FirstOrDefault(); if (user == null) { throw new ApplicationServiceException("no such user"); } if (!user.Login(password)) { return false; } _userRepository.Update(user); Context.Commit(); return true; }
第一部分代碼我們可以認爲通過Email來獲取User領域模型,讀取到領域模型後調用user.Login()方法。這同樣說明了這樣一個事實:Service層沒有任何業務邏輯,所有的邏輯都應該在Domain。
2、User領域模型中的Login實現:
public bool Login(string password) { Contract.Requires(!password.IsNullOrEmpty(), "password can not be empty"); var hashedPassword = new Password(Password, Salt); if (hashedPassword.IsCorrectPassword(password)) { LastLoginDateTime = DateTime.Now; return true; } return false; }
正如你所見:這些邏輯反應出了一個用戶登錄的實際邏輯是什麼,而這些邏輯全部都應該歸屬於Domain。
整個方案代碼提供下載:https://git.oschina.net/richieyangs/BookLibrary.git