[Unit Test Tricks]Extract and Ov

之前介紹了 Extract and Override 的技巧，使得不需改變 production code 對外的 API，也仍然可以在測試專案中建立一個 SUT 的替身，覆寫想要 isolated 的 dependency 就可以針對 SUT 做 isolated unit test 。
但手刻 SUT 的替身總是不如 mock framework 看起來便利，這篇文章要介紹使用 moq 來節省手刻 SUT 替身的 effort, 直接透過 moq 來 stub SUT protected virtual 的方法。

前言

在 [Unit Test Tricks] Extract and Override 這篇文章中介紹的手法，可以輕鬆地將測試目標需要 isolated 的 dependency 部分擷取到 protected virtual 方法後，在測試專案中手動刻一個測試目標的 proxy class ，使得既可覆寫掉需要 isolated 的 dependency 部分，對這個替身進行測試，又與測試目標的行為幾近完全相同。
但手刻替身物件這件事，就像一般 mock framework 想要解決手刻 Stub 物件的困擾一樣，手刻總是顯得愚笨、不美麗、浪費時間。

但因為測試目標的 protected 方法，並不會暴露給外界看到，也因此一般的 mock framework 即使想要 stub protected 方法的回傳值，也無計可施，因為 stub 物件仍然看不見 protected function。

Survey 了一陣子，發現 NSub 有一個 API 叫 Partial Sub ，貌似就是用來解決這問題，但很可惜的是，他也只能針對 public virtual 進行覆寫，而非 protected virtual 。

但 Moq 辦到了，透過 ProtectedMock
來改變 protected virtual function 的行為。

Sample Code

情境：當今天是星期日的時候，就應該是爸爸做家事。如果不是星期日，就是媽媽做家事。

    public class HouseWork
    {
        public string WhoShouldWork()
        {
            var today = GetToday("whoCares");
            if (today.DayOfWeek == DayOfWeek.Sunday)
            {
                return "Dad";
            }
            else
            {
                return "Mom";
            }
        }

        protected virtual DateTime GetToday(string whoCares)
        {
            return DateTime.Today;
        }
    }

原本的程式碼，會因為直接相依於 DateTime.Today 而不具備可測試性，所以透過 extract and override 的手法，將 DateTime.Today 搬到 protected virtual 的方法中，供測試專案的類別進行覆寫，供測試程式注入。

注意：這邊 GetToday() 之所以傳了一個用不到的 string ，只是為了帶出來 moq 在覆寫 protected 方法時，參數設定的注意事項。

Isolated Unit Test with Moq

使用 Moq 撰寫的測試程式如下：

        [TestMethod]
        public void Test_WhoShouldWork_TodayIsNotSunday_Should_Be_Mom()
        {
            //var target = new HouseWork();
            var target = new Mock<HouseWork>();
            target.Protected()
                .Setup<DateTime>("GetToday", ItExpr.IsAny<string>())
                .Returns(new DateTime(2016, 4, 16));

            //var actual = target.WhoShouldWork();
            var actual = target.Object.WhoShouldWork();

            var expected = "Mom";
            Assert.AreEqual(expected, actual);
        }

        [TestMethod]
        public void Test_WhoShouldWork_TodayIsSunday_Should_Be_Dad()
        {
            //var target = new HouseWork();
            var target = new Mock<HouseWork>();
            target.Protected()
                .Setup<DateTime>("GetToday", ItExpr.IsAny<string>())
                .Returns(new DateTime(2016, 4, 17));

            //var actual = target.WhoShouldWork();
            var actual = target.Object.WhoShouldWork();

            var expected = "Dad";
            Assert.AreEqual(expected, actual);
        }

可以看到註解的地方，是最原始測試程式的寫法，但這樣會因為 DateTime.Today 而不具備可測試性。

透過 moq 的 Proected() ，就可以針對 GetToday() 這個 protected 方法進行 Setup() ，因為方法可能是多載的，所以得透過 argument matching 來告訴 moq ，我們想要覆寫的究竟是哪一個 protected 方法。所以必須傳入 ItExpr 的 argument。

記得 using Moq.Protected;

接著，當呼叫 HouseWork 的 mock 物件的 WhoShouldWork() 時，裡面所呼叫到的 GetToday() 就會回傳剛剛 Setup() 所設定 Returns() 的日期。

當跑 Today Is Sunday 的 scenario 時，protected GetToday() 就會回傳 2016/4/17 ，如下圖所示。

2016/4/17 禮拜天

結論

比起 NSub 的 Partial Sub 只能針對 public virtual 進行覆寫，moq 實用多了。因為透過 extract and override 通常就是期望不要改變 production code 對外的 API 與封裝性。

然後對比 Microsoft.Fakes 那樣的黑魔法，我還是更傾向 moq 的方式。原因是 moq 只是透過一些方式幫忙省掉手刻替身物件的工，但仍遵循著只覆寫 protected virtual function，而且相比 Microsoft.Fakes 仍是輕量化許多。

最後，就是我有點陷入了兩難。因為我實在喜歡 NSub 的簡潔，但實務上我又用了許多 extract and override 的技巧。或許，我可能會同時參考 NSub 與 moq 兩個 package 吧。（笑）