自動測試與 TDD 實務開發 第六梯 心得紀錄

前言

這堂課在今年年初時就非常想上,

當時只是想著要如何提高自己的程式品質,

如何脫離交付程式碼那種抖抖的感覺,

改Code永遠都在考驗眼力的自我測試。

推薦

建議大家來上這堂 自動測試與 TDD 實務開發 ,

這一堂課真的不只是教你如何操作軟體與空泛的理論,

而是真正以符合實際狀況的例子去讓你思考,

並有作業輔助你真正自己開始做練習,

還有專人幫你Code Review真的收穫良多,

千萬不要錯過   !!!

詳情請往下看,或是點選報名後略過此頁 XD

對自己的承諾

在上這堂課之前其實有對自己的一點小期許,

希望自己可透過這幾天的課程學會TDD精隨與個人開發一些突破,

並希望可以透過上課的參與交到一些志同道合的朋友。

Day 1  ( 7 / 2 )

首先整個TDD課程架構的技能樹,下面列出了我們將在這幾天點到的天賦。

提到了真實開發常遇到的痛點 

上午

介紹了測試的一些相關知識與你需要知道的一些事情,

其中我最喜歡的是 3A原則

能夠清楚將測試分為三個部分(Arrange、Act、Assert),

這讓大家撰寫的Test Case有著一定約定,

讓後面讀這段Test Case的人可以更快了解自己需要Trace哪一部分。

 

下午

開始由淺入深的介紹原生Unit Test與各種好用套件用法,

與練習早上所學到的一些概念。

在這一部分中我最印象深刻的是如何處理相依的問題,

相信各位在實務上面一定會使用到其他的Service,

對那時的我來說這是一個非常煩惱的問題,

我該當作他不會錯嗎?如果測試沒過是相依Service出問題還是本身程式有問題?

上面這些都是那時的我還沒找到答案的。

經過91從不依賴任何套件的方式去展示該如何做到這件事,

並清楚展示自己在做這段流程時,

是如何使用Visual Studio 2015幫助處理繁瑣的動作

(這一段是非常精華的步驟,書上、網路上的文章可能可以告訴你Code長甚麼樣子,但是他沒有Coding的過程,高手之所以快是因為他懂得如何將時間都花在邏輯上面,而不是在打字上面)

在自己手刻Stub的過程你可以理解你為何要這麼做,

也了解到物件導向不是好看的,

而是為了解決你當前的問題的好方法,

後面使用了Stub/Mock Framework的協助,

簡化我們模擬外部互動的成本與步驟,

讓測試案例與Production Code 更簡潔。

番外篇

在課程結束之後跟周遭同學們要了聯絡資訊創了群組討論功課與一些上課、工作的想法,

其實我覺得這樣的感覺很不錯,

學習的路上面有人可以互相討論與砥礪是很不錯的,

或是在分享自己的經驗的同時也是Review 自己是否有不夠完善的地方。

哈哈,這個開始也許也是我們能夠兩次拿到積分第一的關鍵呢 XD

Day 2  ( 7 / 9 ) 

今天課程是網頁的測試,本身目前工作是寫網頁所以這部份非常聚精會神地在聽。

原本自己預期會聽到的是ASP.NET MVC 的測試,

結果居然是 WebForm 真是太讓我驚訝了 XD

這不就剛好可以套用到目前的專案上面嗎(目前正在修改前人留下的史詩鉅作,Lab完全符合真實案例),

  1. 使用了 Selenium 這套工具錄製了網頁預期的行為
  2. 匯出成 MSTest Unit Test
  3. 抽Page Object ( 讓畫面與邏輯真正解耦 )
  4. 開始針對醜陋的程式碼重構
    1. 只有在綠燈狀態下才重構
    2. 根據你擁有的資源決定重構到哪個層次
    3. 要想著外部如何取用你的API,是否方便
  5. 完成重構,並通過所有測試

其實到這邊會發現,其實教學並不是針對單純的TDD & Unit Test,

而是以一些簡單的範例展現出實務面上可能會遇到的問題,

以及你該具備處理的能力。

番外篇

這天靠著我們強力的隊友 - + →(人名處理完成),

回答了一題Bouns讓我們取得了這次的積分第一,

感謝他的努力 XDDD

Day 3 ( 7 / 16 )

上午

今天的上午是討論到了一個問題,

測試該如何產生出來呢?

由於需求是使用者或是PO交付給開發人員,

那他們可能不會懂Class層面的Unit Tests,

在今天早上學會如何透過 Cucumber 的 Gherkin 語法來描述需求,

並在.Net的 SpecFlow 套件協助下產出測試的基礎框架,

我們只要在其中依據TDD的原則與概念去完成測試,

是十分直覺與感到舒服的,

也會看到自己的設計有了不一樣,

會開始從外部呼叫的角度去思考該如何設計。

下午

這邊也丟出了一個非常常見的Lab,

我們該如何針對與DB相依的需求進行測試呢?

我們可以透過SpecFlow + EntityFramework來進行範例,

在SpecFlow Event Hook將資料做初始化與清理資料動作能確保無論測試是發生甚麼事情,

資料都會維持在原本的狀態不受影響,

並透過SpecFlow table extension method,

直接建立Instance或是集合,

並在Assert做比較。

黑暗兵法篇

一直以來跟PO/PM/SA討論需求都是一件很累的事情,

或是根本討論出來壓訂好的結果也不確定是否是正確的,

我們可以透過Given/When/Then與table方式,描述 scenario

讓我們一開始已經有一些測試資料可以GO,

將這些東西記錄起來並寄郵件確認後可以開始進行,

往後如果有需求變更也是依照此法進行新增Given/When/Then與table方式,描述 scenario。

強調PO可以少寫很多需求文件,只需Scenarios跟商 業邏輯文件即可。

番外篇 

今天91問了一個問題誰回家有做Lab練習的呢?在我們自己這一排有加LINE群組內其實我們時常都在問別人作業進度與討論LAB XD

看到別人寫作業自己其實也會很努力地去寫,尤其是你的組員剛學C#,但是在周一、週二已把Lab練習、Homework完成,

你說誰還可以偷懶下去呢 XD 馬上筆電拿起來開始練習跟寫作業!!!

其實覺得最好的學習就是能夠自我燃燒出學習的熱忱,或是透過他人激勵與互相砥礪讓自己也燃燒起熱忱去學習,

覺得這樣的學習過程是快樂的,感謝這些組員拉!!

PS: 結束後吃飯的那一家店好吃 !!

 

戰利品展示

遠征紀念(最後一天到七點多,千萬不要訂太早 XD)

合照