就只是想講一些故事。

背景

項目的全部后端代碼有單元測試覆蓋率的tolerance，現(xiàn)在是96.47%。
同時我們有一個Attribute [皇馬甲]，只要給代碼穿上它，覆蓋率統(tǒng)計工具就會開綠燈，不會納入統(tǒng)計范圍。是的，96.47%呵呵了。

我們項目是基于一個第三方的基礎(chǔ)框架來進行上層建筑的構(gòu)建，因為依賴于基礎(chǔ)架構(gòu)，所以很多代碼實現(xiàn)上的問題我們身不由己。單元測試UT便是其中之一。凡是跟基礎(chǔ)框架有關(guān)的代碼，寫單元測試的時候主要有兩個痛點。第一，涉及框架的調(diào)用與我們自己實現(xiàn)的業(yè)務代碼有繼承關(guān)系，單元測試不好區(qū)分隔離，所以為了單元測試必須額外動手做一些提取抽象的動作。第二，框架中的model是一個復雜結(jié)構(gòu)的對象，很多單元測試需要構(gòu)建整個對象來完成數(shù)據(jù)準備，但其實業(yè)務邏輯只需要其中很小的一部分，這就造成了單元測試的過程復雜，效率低。從大家的反饋看，第二點更痛一些。

可是，經(jīng)過了estimation的每一張卡，是包括了單元測試工作量的。

故事1

Feature I 非常重要，時間緊迫。
Team 1 同學們壓力很大，十分辛苦。最終仍然按時交付了。
可是后來我們發(fā)現(xiàn)，F(xiàn)eature I的代碼中存在皇馬甲，還包括[皇馬甲("Dev A")]這種?？墒牵桓吨骉eam 1就解散了，分散到其他Feature上。Dev A，因為其他原因離職了。
現(xiàn)在皇馬甲還穿著。

故事2

Dev B 是一位為項目奉獻巨大的同學。也是因為交付時間緊迫，也套上了[皇馬甲("Dev B")]。
在聽聞Dev B要roll off的時候，同學們就多次提醒，不要重現(xiàn)Dev A的事故，人走了，皇馬甲還在。
然后在Dev B roll off的當天party上，他說皇馬甲就留下吧，“來過，奮斗過”。大家笑，現(xiàn)場氣氛和諧融融。

故事3

Dev C 是一位研學大師，建樹不限于微服務和DDD。不同與A與B，他還在為項目奉獻著。
但是他對痛點二深惡痛絕，曾言，“在這樣的情況下寫出的UT，沒有意義，不可讀，不可維護，純粹是浪費時間。你們看，我給你們找找別人是怎么做UT的，你看這樣的UT就很清晰，數(shù)據(jù)準備簡單，Assert清晰....”
所以C偶爾會使用皇馬甲技術(shù)來提高工作效率。

故事4

Dev D 是在其他項目結(jié)束了之后onboard到我們項目上的，我們項目的業(yè)務確實復雜，要花時間弄懂很多業(yè)務知識。
所以他開始的幾張卡，交付周期都比估點的時間要長，身為新人，壓力就會很大。所以為了減少交卡的時間，他選擇先使用皇馬甲技術(shù)，等休假的時候再額外花時間補UT。

....

是的，以上幾位理由都成立。你猜，我們在一家什么樣的公司，你猜，他們幾位分別是什么職級。

客戶以為交付的feature是有UT cover的，是有保障的。
客戶以為安排的工作量是合適的，team不會覺得壓力太大，大家都只需要每天8小時就好。
同學以為自己的單元測試邏輯覆蓋有問題，因為pull了最新代碼，覆蓋率居然降低了。
同學以為pull rebase之后就可以交代碼了，結(jié)果覆蓋率低過tolerance，被Block了。
QA以為在拿到卡的時候，UT已經(jīng)run過了，基本保障是有的。
SM以為每個迭代統(tǒng)計的數(shù)據(jù)是真實的，估的點數(shù)映射到人·天是沒毛病的。

我以為我們的目標是一致的，是一個team，責任一起扛。現(xiàn)在的感覺特別像當年上大學的時候住寢室，衛(wèi)生只有我打掃，廁所只有我去刷。

有個不方便透漏名字的人說過，我們都不是這家公司的好職員，我們都在干著臟活累活。