15 days ago

今天是中秋節,也是我們全棧班的最後一天。全班大多數同學都更新了自己的心得,我自己也決定來更新自己的結業心得。

我過去幾個月都沒有更新博客,有一些人應該納悶,我幹嘛去了?

這兩個月呢?我把台灣的班都停了。跑去北京搞 新生大學全棧營 去了。

全棧營的起因是這樣:李笑來老師,某天在網路上發了一個感悟「一年可以成長為全棧工程師」。但莫名其妙的這句話,就在大陸被黑出了翔。

在我這個外人看起來很莫名其妙的原因,其實是因為在矽谷呢,說這句話根本沒多少人會大驚小怪,甚至是把你黑出翔,但在中國莫名其妙的就變成了政治不正確。

隨便找了一下 Quora,看到這種題目也沒被戰....大家還積極討論? How can I be a full stack web developer in one year?

全棧工程師的定義,以及所需成長時間

  • 一年可不可以成長為全棧工程師?可以!如果你找到夠好的前輩帶你,以及在夠好的實戰環境,肯定可以。
  • 再來是「全棧」,有沒有一個定義?
    • 是在前端、後端、CSS、機器調效都練到大牛等級?
    • 還是在創業公司,可以一個人全搞定這些,產品還可以快速前進?
    • 還是心中想開發一個產品,可以自己一人從零到有生出來順利上線?

好吧。如果我們先不管這些。

若求「一組無經驗新手,是否可以在八週之內搞出一個實戰等級產品並上線」,這件事何以可行?

許多人也許覺得「現實世界不可能發生」。但就我以前帶產品以及帶徒弟的經驗,我卻認為「這應該是有可能的」。(注意,這裡是講「應該有可能」)

快速帶出職業選手,本身就是業界常態

我本身在業界多年,我是知道這幾件事的事實存在:

  • 幾乎稍微成熟的 Rails 公司是有帶徒弟的套路的。(你不可能招一個零經驗新手,手把手教三個月,才能跟資深程序員一起寫,許多公司如 Facebook 甚至有新人 Bootcamp )
  • 所有的互聯網產品,其實都是有開發流程套路的。只是依不同公司的開發團隊資質,需時從 2 個月到 9 個月。
  • 很多厲害的 developer,本身不是計算機本科出身的,公司一樣帶的起來...

所以,理論上、理論上,如果找到「學習上的瓶頸」「開發上的瓶頸」的相關答案的話。理論上、理論上,應該有一套方法,可以讓這件事(「一組無經驗新手,在八週之內學會編程,並搞出一個實戰等級產品上線」)發生。

我自寸已經知道這其中大多數問題的答案。問題是:我真沒試過,是不是能夠把這些答案組起來,放到一個團隊,按照這樣流程跑,就能達到同樣的效果?而且,即便這應該是可行的,可真沒人相信我。

況且,這世界不存在這樣的公司,也不存在這樣的團隊與機會。

如果我說要開個班說能辦到這事呢,估計許多人都會認為這是大忽悠。

全棧營其實是一場教學上的實驗

這個機會起源於:當時在 Twitter 上,當所有人都在罵李老師時,只有我無心的回一句,我認為絕對是可以的(因為這在西方世界很正常嘛)。

所以李老師就把我叫去北京瞭解看看,這到底要怎麼搞?畢竟這事要是幹成了。就是編程教學的一大突破。

而我當然是一口答應這個機會的。因為:

  1. 四周內培養職業 Rails 工程師,能獨立開發個人產品。這事肯定是能幹成的。我在台灣這樣的班就辦了快十期。
  2. 其餘關於做產品所需的相關知識與坑,這幾年來我做了深入的研究。在我的心中反正是這樣想,我已經離所有的答案都只差最後一步了,只差有人自願讓我做實驗而已。

能有人幫我推最後一哩路,我當然是極其開心的。

最後我就接下這個挑戰的任務,甚至還跟李老師大膽的說:

我不需要三個月,我只需要兩個月。

(估計那時候腦子應該是燒壞的)

但是,我想先在這裡先跟大家透露最後的結論:

其實不需要八週,只需要七週。。。。。。。。。。。

我是如何設計課程的

全棧營的課程表,這樣說吧,真是寫好玩的。這個營,在課表上列的知識都會教,只是絕對不是按照課表上的進度走。這個課表只是為了「政治正確」寫的。

這個營真正的課表是這樣的:

  • 前三週,新兵基礎訓練(我有一套特製的教材保證打底,至於運作原理,那就不在這篇文章範疇之內,改天再提)。這段期間,同學會開發好幾個「個人」項目,確保自己最少有辦法做到獨立的開發。
  • 後五週,團體協作訓練。同學要自己想辦法想出有趣的產品,製作 Landing Page,利用 Landing Page 招募至少四個同學一起實作,然後用課堂上教的專案管理技巧,小組進行敏捷開發實作。最後呢,再利用 Onboarding 技巧收尾。

我壓根就不走也不信全世界培訓班都在做的那一千零一套(也就是上課花了大把時間教基礎知識,畢業前兩三週再做一個玩具 project)。這個班,我就打算走我研究認為有效的那一套,而且要做結業 project 就是全玩真的。

而且,我是開學第一天,才跟班上同學說,上課貼的課表都是假的。不算數,我走的是這一套。他們都懵了。(畢竟學費不是小數目)

這幫學生遠超過大家的想像

前三週的進度,我是非常有把握的。我在台灣就已經能夠這樣幹,一點都不擔心。

但後五週的設計,其實我是完全沒把握的,哈哈 XD

我只是猜「應該可以吧......」,就這樣幹了,但不行也得搞看看。所以我就真的這樣做了....

猜猜到第七週學生跟我抱怨什麼?

「老師我們把項目已經做完了,下週要做什麼?」

老師,我覺得班上畢業氣氛太早了,不太好」

……這也太狂了。我壓根沒想過他們能夠提前做完,還提前一個禮拜!!搞得我最後一週,只好臨時去寫一些投影片墊檔講課 -_-|||

學生作品 1:

人才火箭 http://talent-rocket.herokuapp.com

學生作品 2

HackSchool https://hackschool.herokuapp.com

學生作品 3

GrowthHackCN http://growthhackcn.herokuapp.com

學生作品 4

約霸 http://online-ask.herokuapp.com (留學咨詢項目)

2 天 Hackathon 作品

在畢業那一週,同學還幹了一件更瘋狂的事:兩天 hackathon 又搞一個真實產品出來(含 landing page 與 onboarding)。

濃縮書:http://nongsuoshu.herokuapp.com/ ( by 人才火箭隊組員)

你說這幫同學,兩個月前沒人會寫代碼(20人內只有3人有過去編程經驗),誰相信?

我真不怪其他人不相信,因為是我也不相信!但他媽的他們做到了!

全棧營教了什麼

  • (基礎期)基於認知心理學的編程學習法與正確的自學法。可以快速上手 Rails API,並獨立
  • 如何做 Landing Page
  • 如何寫 User Story,以及 run Standup Meeting 以及優先權排序
  • 每天的收尾會議(仿 thoughbot 內部流程)。
  • 每週的 Retrospetive Meeting
  • 如何寫乾淨的代碼以及設計架構
  • 如何做 Onboarding (如何讓 RD 等級的「屍體級」產品,變成運營等級「活人」產品)
  • 仿 Hackathon 的散彈槍開發法

讀到這裡,讀者們如果識貨(有做過編程工作),應該知道這是什麼樣等級的訓練。其實甚至我都害怕他們承受不了這樣高強度的技巧與操練。結果....

讓我覺得果然教編程還是要教新手,新手沒玩過這些東西就不知道害怕....

(P.S. 給沒有做過編程開發的讀者一些背景知識,這是有靠譜 V.P. of Engineering 的 A 級團隊內部才能夠這樣高效的做產品,可以理解成為我在給新手吃人參)

為什麼要這樣教?

  1. 我自己也相當不認可一般培訓營裡面的課表設計,我認為那些課表是相當不靠譜的,一般人根本就記不住那些無聊知識。花了三個月只做出一個玩具,這是在浪費人的生命。
  2. 許多培訓班的教學方法,是仿大學工業教育設計課表,只因為大家普遍認為大學這樣教,竟然社會上就得這樣教。問題是這根本不是業界培養開發者最有效的方式(社會上是師徒制以及做真 project 的帶練)。既然這個方法不有效,為什麼要這樣教?
  3. 培訓班不教真實的場景以及解題思路,以至於培訓班學員畢業了以後,適應困難。社會上許多人對於培訓班學員有幾個印象
    • 1) 沒有辦法按照真實需求,獨立作業,脫離了培訓之後就失憶
    • 2) 在業界真實協作感到困難
    • 3) 這些培訓班學員之前沒有計算機底子,所以自學遠比野生程序員更慢...

種種原因造成了很多人聽到求職者是培訓班學員,就退避三舍。

所以我非常想照自己的思路,設計一個:我自認非常有效的學習途徑(起碼這條路上學的都是業界實務),培養真的社會上所需要的「容易合作以及善自學的好程序員」。而不僅僅是「只能夠 CRUD。。。。。」。

為什麼挑選這些題目教?

在台灣我做了快十期班,也成功帶出很多程序員。其實我的教法已經非常有效率。

但是呢,我卻發現一件事,這些班下來,我僅僅能教出能夠獨立「寫功能」的程序員。

但是我教不出「能夠做出有靈魂產品」的程序員。

所謂「有靈魂產品」的程序員:指的是他們做的產品一上線,就已經是打磨過的產品,而不是「只有功能,但卻沒人知道怎麽使用的屍體」。也不是只會做功能,還要找運營、行銷來回吵架產品一直搞不上線的程序員。

別說「能夠做出有靈魂產品」的程序員了。因為很多時候,產品準時上線都相當困難。

在這個業界,撿到一個能夠達到這樣要求的程序員就是寶了。

所以,我一直在想,這樣的人能不能夠量產。我想要幫世界量產,這世界需要更多這樣的「全棧程序員」。會項目管理,會做運營的程序員。。。。

這個班就是這樣的實驗。

我很幸運的,實驗如我想像的成功,而且比我想像的還要成功(提前一週做完)。

如何在四周開發實戰等級產品

其實我一直在掙扎,我要不要把這些秘笈公開出來。考量的點有幾個:

  • 一旦公開出來,應該就會有競爭者抄我怎麼做。畢竟我在運營一個教學事業。
  • 但是如果不公開出來?這世界明明就應該運營的更有效率,而且很缺程序員。連我自己都希望業界有大量的這樣等級的程序員可以招。不寫出來我內心始終覺得哪裡很怪....

想了很久,最後決定還是把這個秘方寫出來。我想至少至少,這套秘笈,可以讓許多正在做產品的團隊,加速內部產品開發的速度以及少走很多冤枉路。

做產品的步驟 Step 1: 做 Landing Page 吸引用戶

五週的第一週第一天,我教 Landing Page 製作 (以前在 GrowthHack 班有教)。

之所以為什麼一開始教 Landing Page 而不是項目管理。是因為我以前在做產品時,發現一件事,很多程序員或創業者,做產品時往往都是一頭熱的就栽進去寫 code,快上線了就...

  • 直接上線,但是用戶不會用,直接陣亡 。(此稱「屍體級」產品)
  • 請營銷搞了一個 Landing Page。但是營銷寫的文案與產品內裝,差太遠。營銷認知的「產品價值」,與程序員寫出的「產品功能」差得太遠。首頁文案變成詭異的四不像。

所以:

  • 既然是要做有意義的產品。那不就得在第一天就要搞清楚自己能夠 Offer 使用者的價值嗎?
  • 以清楚的價值觀出發的產品,功能方向開發不是才不會歪嗎?
  • 如果連 Landing Page 都做不出來,表示自己根本不清楚這個產品的價值與這個市場的痛點?如果根本吸引不到用戶使用,甚至隊友一起開發?那麼學敏捷,高效開發出一個垃圾有何意義?

學生必須先製作一個 Landing Page,成功吸引同學這是一個誘人的產品,然後同學進行投票,按照志願分發到他想加入的組。

做產品的步驟 Step 2: 進行項目管理,只做「有價值的功能」

要做一個有價值的項目,是需要很多道加工的。

真實的世界,很多時候,用戶雖然喜歡你能夠解決的方案,但市場窗口是不等人的。必須得在市場窗口關閉之前,做出來並且上線。

所以:

  • 小組進行 User Story Mapping,討論什麼是「Must Have」,什麼是「Could Have」。其餘程序員個人的「私心與貪心」全部扔到抽屜裡,有空再做。
  • 利用 Tower 進行項目分派。
  • 利用 Pull Request 進行代碼協作。

做產品的步驟 Step 3 : 建立程序員的公德心

產品團隊為什麼總是 delay 上線?鑑於這十年內我見過了形形色色的程序員,所以對於開發方向進行這樣的閃坑指導:

  • 大家在協作的主幹 develop branch 必須要是「不會爆炸」的代碼。
  • 大家部署到 heroku 的 master branch 必須是「可操作可驗收」的實際產品
  • 每天晚上六點由團隊主力程序員 Merge,部署 Heroku
  • 每天課程助理會收「各組錄製的產品功能 Gif」,確保隊員交出的當天成果是「可用功能」而不是「亂寫的功能屍體...」
  • 每天早上 Standup Meeting,確保今天的主線是正確的
  • 每週五早上有「產品展示會」,每週開發的產品功能要展示給全班同學看,給全班同學玩,讓大家指教。如果週五交「屍體」的組,會被我在展示會時釘在牆上。。。。。
  • 每週五下午 Retrospetive Meeting,重新檢視每週項目版上的功能「什麼是相對重要的」「什麼相對是不重要的」
  • 每週五下午要開「分享會」,同組成員分享「本週自己學到最好的知識」「本週最坑爹的事」

做產品的步驟 Step 4 : 對產品做 Onboarding ,進行最後一道打磨工序…..

鑑於 Step 2 與 Step 3 ,所以同學的進度是很神速的。大概做到第三週快結束,領先組的同學突然就要求我加入他們的例會討論救他們....。(我大概每週只參加他們的 Standup Meeting 一兩次,確保方向不要歪得太誇張)

因為他們發現即使不管再怎麼努力做功能,做出來的網站雖然精緻,看起來還是像屍體。不知道要怎麽往前推進。

所以我教了他們最後一招: Onboarding (以前 GrowthHack 班有教)。

User Onboarding 「用戶引導」,也就是要讓新用戶註冊後,服務可以透過一系列的互動引導,具體的流程決定了用戶是否會回養成使用產品的習慣並成為回頭客。

利用一系列的 Onboarding 問題,抓老公、男朋友、別組同學、課程助理、微信朋友圈的路人,來當真實 User,對這個網站進行以使用者角度的批判。

  • 不管什麼角度都可以寫,至少寫出 50 條
  • 團隊再拿這 50 條,開個檢討會,一一把 solution 寫出來。
  • 重新檢視這些 solution,哪些是可以做的,哪些事不能做的。
  • 哪些功能做得正確,打磨得更為人性。哪些功能是冗余的,毫不留情地砍掉。

然後,他們再花一週,把這些「Bug 全修掉」。

以這樣的步調,同學有一組是四週就把產品上線了....。最後一週就沒事幹了。

人才火箭 http://talent-rocket.herokuapp.com

乃至於這組最後一週,還花了兩天的時間跟又硬幹了一個小專案當 Hackathon 打,在畢業典禮上展示。兩天能做出的成果真是相當披敵當年我去打 Hackathon 的功力。。。。。。

濃縮書:http://nongsuoshu.herokuapp.com/ ( by 人才火箭隊組員)

隊員日記:http://nfreeness.logdown.com/posts/2016/09/16/like-the-moon-not-the-same-mid-autumn-festival-of-9-15-journal

結語

分享這篇文章,其實真不是想炫耀這個班多牛逼,自己又多會教云云。說實話,我教學的技術並沒有多厲害,我只是教同學:

  • 一般公司應該就得這樣做專案的方式
  • 一個好的程序員,做事基本的態度
  • 分享、檢討,才是前進的加速器
  • 做任何產品與功能應該基於價值
  • 自學的功夫,才是真正應該帶走的精華

我的初衷是:

  • 培養對這世界能做出貢獻的程序員
  • 學編程不該這麼難,這麼花時間。我覺得這世界應該有更有效的方式。
  • 學生「努力」與使用「正確方法」的學習,遠比有沒有計算機背景更重要。

我更感謝同學願意花這麼多時間賭在這個班上,認真的一起搞這個實驗的 Project。

更讓我見識了大陸同學的認真與狠勁,這個班要是辦在台灣,我真不知道有沒人願意一起玩命的這樣「認真投入學習」。

最後,為什麼會分享這一篇文章所談到的教學技術?用膝蓋想都知道我耗費了洪荒之力,才證明出來這個實驗結果。我再會教,也量產也量產不出個什麼鬼。

我只關注 更在乎這個世界的編程教學法,是否能夠被大幅改變

與其關注教學技術是否可以獨佔,我更在乎這個世界的編程教學法,是否能夠被大幅改變。有更多的程序員誕生出來,這世界會變得更加有趣。我更希望人家 clone 我的教學法,一起去改變這個世界。

  • 謝謝耐心看完這篇文章。若有興趣交流,歡迎寫信到 xdite@growth.school

  • 若是想報名,請關注我的微信公眾號 xdite-growth。(我們第二期已經滿了。第三期至少估計要等 2017/1,所以這篇真不是什麼招生廣告文 )

P.S. 2016/09/15 中秋節,這是人生當中過得最開心的一個中秋節。

全棧班的最後一個 slide

學生的優秀博客

(週記每週更新)(基本上我們有 20 個博客,全發大家估計看不完...)

 
21 days ago

我開公眾號了。歡迎掃碼關注!(或微信搜尋 xdite,有貓頭鷹那個 )

這個公眾號會專注更新幾個領域的內容:

  • 認知心理學
  • 學習
  • 自我成長
  • 編程學習理論

歡迎舊雨新知,掃碼追蹤。並分享給朋友訂閱,大家一起升級!

 
3 months ago

過去一年,莫名其妙成了全職的程式教練。大概是天注定,唉。最常遇到的新手問題就是,請問如何入門 XXX 技術。當然,對我來說,寫 Rails 都快十年了。這這個領域東西還真難不倒我,抄了傢伙就幹已經是我這幾年的風格。

不過我一向蠻有實驗精神的。為了要能夠回答這個問題,我特地去重學了新的程式語言( Ruby Motion ),來近距離觀察重新拆解我十年以來的學習反射性動作到底是什麼,來寫一份給新手的參考指南。

Step 1 : 建造時光機

我在學習新技術時,會用到兩個東西。第一個是 Git,第二個是 Redmine。

Git

git 是新手的時光機。我認為如果一般人學習任何程式語言,甚至寫任何筆記,都應該上個 git 版本控制。起碼看你上一次寫了什麼東西。其實 git 一開始也不用學太多指令,練習以下幾個就夠:

  • git init (初始一個 Repo)
  • git add [檔案名稱] (將某某檔案加入版本控制)
  • git commit -m "儲存訊息" (將這次要加入版本控制的檔案,寫入歷史紀錄)
  • git checkout -b "新分支名稱" ( 如果要實作一個蠻巨大的實驗性功能,我通常會開一個 branch)
  • git checkout "分支名稱" ( 切換不同分支 )
  • git push (推送變更到遠端做一次備份,通常是 Github)
  • git pull 拉下遠端的變更

主要是將做過的東西,「每一個 interaction 都做一次備份」,讓自己知道當初為什麼做了這些變動。

Redmine

Redmine 是一套專案管理系統。不過在這裡我是利用它的「樹狀 ticket 系統」去規劃我的練習。

我運用的方法如下:

  • 大致切出第一層,我覺得我想要練習的主題
  • 然後中間要是有遇到難題,大概 30 分鐘解不開,我就會「放棄」,然後開另外一張票,隔天心情比較好再回來學
  • 中間我要是覺得「有個功能實在太棒了」,我應該可以來做。忍住,開出另外一張票,下週再來做。
  • 每一張 Ticket 我拿來記幾個東西:
    • 我這次找到了哪些 link(幾乎是一 google 到一個疑似可以用的資源,就 copy 一份)
    • 這次這個功能寫了哪些 code。(是的,我不止 git 記了一份,redmine 上還複製了一份)
    • 這次我做了哪些改動
    • 我之前的「錯誤做法」,為什麼錯了。bug 的原因是?
    • 為了解 bug 所找到的 stackoverflow 資源

我的 redmine ticket 記這些東西,每張非常的詳盡。(不是指筆記做得好,而是指這當中的過程,我把每一步幾乎都錄下來)

這樣做的好處是:

  • 我不會分心,專注在我當初想練的主題上
  • 我不會被鬼打牆的 bug 打擊到自信心全無
  • 我不會被自己一時的成就產生的「傲慢感」牽走
  • 把每一步包括 bug 都錄下來。bug 的產生以及解法,其實是「重要的知識」。因為 git 「往往只會保留正確的結果」,而不會保留你 debug 的結果。然後下次自己還是會掉進同樣的坑裡面。

Step 2:挑選合適的主題,熟悉基本工具

在無數篇自我的學習部落格我都曾經提到過,在自學過程中保持一定的「成就感」是很重要的。最近,我把我多年來練習題目做了一個總結,找到了一個模式。

超級新手:

  • 一個「單一功能」,CRUD 的練習。
  • 先做 R 再做 C 再做 D 再做 U。

完整做完一輪,搞懂怎麼樣讓這個專案會動的基本因素與語法。

(注意,這個系統內只有「自己」這個用戶)

新手:

以下按照順序

  • 除了 CRUD 外的三個功能
  • 這個系統內只能有 1 個角色,通稱「使用者」。
  • 登入系統
  • 套版
  • 加上一個外掛功能
  • 部署

(這個最實際的例子就是 TODO + 使用者註冊 + 套版 + deploy)。這一系列做出來,起碼可以讓一個人至少可以熟練這個系統的最基本工具,而不太容易絆倒。

中手:

  • 第 2 個角色
  • 開發者認為的 10 個重要核心功能
  • 至少加入 3 個外掛
  • 權限
  • 介接一個第三方 (學會讀文件)

之所以會建議這樣做的原因。是我發現每當建議新手自己找題目練習後,他們自己想的題目反而變成了災難。

說災難的原因是因為他們挑選的題目帶給了他們濃厚的挫折感。而這當中最核心的原因在於失控的 scope。

而 scope 的最主要的控制變因在於「這個系統裡面有幾個?操作角色」。很多人會忽略掉一個重要的事實,開發系統裡面多「引入一個使用者角色」,這個系統的複雜度就會成「等比級數上升」。

舉個例子來說好了:

  • 一個匿名論壇,大家可以上去發表文章。
  • 一個實名論壇,大家必須要登入才能發表文章。
  • 一個實名論壇,大家必須要登入才能發表文章,「並且針對它人的文章留言」。
  • 一個有管理員的實名論壇,管理者可以任意刪除大家的文章以及留言。發文者也可以砍掉自己文章底下的留言。

這四個例子的功能數量是「等比級數的上升」。而一旦新手挑的題目,系統內角色多於 1 人,基本上就注定「打挑戰級難度被王打死」。

而我一向的學習方式,都是會儘量讓難度可以控制在自己「開開心心學習」的程度上(每次逐步加重,而不是一開始就被滅好玩)。我知道唯有己有成就感地學習,學一門技術才不容易中途而廢。

Step 3:將 Redmine 的筆記整理成技術文章

在學完這整套技術後,我會在適當時機,把過去的筆記寫成一篇技術文件。視情節發布給同事或給部落格讀者。

  • 比如說這個專案如果是跟同事協作的,我會在拉 pull request 時,附上快速的一篇 getting started 。
  • 如果是這個技術難度比較高,用一篇 getting started 的方式很難讓對方快速掌握,我會至少做一份 newbie guide ,讓想學的人,透過 guide 帶練至少一次快速衝到新手等級。

因為 redmine 上當初的筆記非常得詳細,在看這些筆記與 git 的時候,我當時的記憶就會被喚醒。甚至上面有現成的 code example 可以直接拿來改編。

而把這些筆記整理成技術文件與指南非常有幫助,因為「寫作」這件事可以幫助我從此把這門新技術「想通」,而且烙印到大腦裡面。

總結

以上的步驟,最後可以總結成三個重點:

  • 建造時光機,與錄下自己學習的過程
  • 做有成就感的題目,透過控制「角色」去控制複雜度,在頭兩個循環就掌握到基本工具,而且做出有成就感的東西。
  • 重新複習,寫成文章,內化成自己的架構。

分享給大家。

 
4 months ago

Mocking

在這個例子裡面,我們用了 mock 手法,確認 show 這個 action,真的有去呼叫 Suggestion.find

  • allow(Suggestion).to receive(:find).and_return(suggestion)
  • expect(Suggestion).to receive(:find)
  describe "GET show" do

    it "assigns @course and render show" do
      suggestion = double(:to_param => "123" )
      allow(Suggestion).to receive(:find).and_return(suggestion)
      expect(Suggestion).to receive(:find)

      get :show, :id => suggestion.to_param

      expect(response).to render_template :show
      expect(assigns[:suggestion]).to eq(suggestion)

    end

  end
class SuggestionController
  def show
    @suggestion = Suggestion.find(params[:id])
  end
end

劣勢:順序「反直覺」

但是其實這樣的寫法,對於我們之前提到的 Four-Phase Test:

  • Setup (準備測試資料)
  • Exercie (實際執行測試)
  • Verification (驗證測試結果)
  • Teardown (拆解測試)

有點相違背了。

我們先做了 Verification (expect)再做 Exercise ( get :show) 。

劣勢:容易失敗

而且在拆解階段,我們會將這段測試重寫成這樣。將 expect 寫在 before 階段,但這樣寫的缺點是,expect 如果不如預期,後面測試會因為 except 全死。

  describe "GET show" do

    before do 
      @suggestion = double(:to_param => "123" )
      allow(Suggestion).to receive(:find).and_return(@suggestion)
      expect(Suggestion).to receive(:find)
      get :show, :id => @suggestion.to_param
    end

    it { expect(response).to render_template :show }
    it { expect(assigns[:suggestion]).to eq(@suggestion)}
  end

Spying

與其使用 Mocking 手法,我們可以改用 Spy 手法,將測試改成這樣。(RSpec 使用 have_received 去驗證)

  describe "GET show" do

    before do 
      @suggestion = double(:to_param => "123" )
      allow(Suggestion).to receive(:find).with(@suggestion.to_param).and_return(@suggestion)
      get :show, :id => @suggestion.to_param
    end

    it { expect(response).to render_template :show }
    it "should find suggestion and assign suggestion" do 
       expect(Suggestion).to have_received(:find).with(@suggestion.to_param)
       expect(assigns[:suggestion]).to eq(@suggestion)
    end

  end

Four Phase 順序不但正確,而且是在 Exercise 後,才做 Verification。

 
4 months ago

double 可以讓我們輕易地閃掉準備「協作者」的痛苦。但是有時候,我們還是可能被「協作者」本身的內部邏輯改變整到。比如說,這裡是一個「建議」Suggestion 表單:

require 'rails_helper'

RSpec.describe SuggestionsController, type: :controller do

  describe "POST create" do 
    context "when suggestion is invalid" do 
      it "render new" do 
        post :create, :suggestion => { :title => "", :description => "" }

        expect(response).to render_template :new
      end
    end
  end
end

class Suggestion < ActiveRecord::Base
   validates :title, presence: true
end

class SuggestionsController 
  def create
    @suggestion = Suggestion.new(suggestion_params)
    if @suggestion.save
      redirect_to root_path
    else
      render :new
    end
  end

  protected

  def suggestion_params
    params.require(:suggestion).permit(:title, :description)
  end

end

如果物件非法的話,要 render new 這個 action。正常來說,這樣的 controller 測試,應該會通過。

但是有時候 controller 程式碼沒有動,但 model 程式碼內部動了,比如說在這個例子,可能多加了新的欄位,或者是新增了其他的驗證方式,導致這個 controller 測試要因為 suggestion 內部本身的邏輯要修改。

這樣真的很討厭。

重寫測試

其實這裡我們根本不應該塞「例子」進去,這樣 suggestion 內部邏輯一旦改變,我們的 controller test 就要改個沒完。我們真正應該要做的是:

  • 準備一個「一定儲存失敗的替身」
  • 然後在 controller 讓 @suggestion.save 鐵定失敗
  • 因為我們要驗證的是 「render :new」

所以我們可以把測試改寫成這樣

require 'rails_helper'

RSpec.describe SuggestionsController, type: :controller do

  describe "POST create" do 
    context "when suggestion is invalid" do 
      it "render new" do 
        invalid_suggestion = double(:save => false) 
        allow(Suggestion).to receive(:new).and_return(invalid_suggestion)

        post :create, :suggestion => { :xxx => "yyy" }

        expect(response).to render_template :new
      end
    end
  end
end

這樣 suggestion 內部驗證再怎麼樣變,都不會影響到這個 controller test。

 
4 months ago

Four-Phase Test 是一種常見的測試 Pattern。幾乎也是一般人在寫測試的手法,依序為:

  • Setup (準備測試資料)
  • Exercie (實際執行測試)
  • Verification (驗證測試結果)
  • Teardown (拆解測試)

但是通常我們在一般寫測試或者是 TDD 時,常常會遇到一些狀況,導致 Setup 階段時,資料「難以被準備」。通常是有以下幾種狀況:

對象物件當中的「協作者」還沒被誕生

比如說都還沒寫到那個 class 或者是 method

對象物件當中的「協作者」是「系統外部物件」

如: API 回傳內容

要準備的資料、相依性過於複雜

要生超多物件才能測試

執行這個測試,呼叫到「吃效能很兇」的 method

導致測試運行緩慢

使用替身

但我們的首要要務,其實是要測我們內部的程式的邏輯,不是要測「外部邏輯」的狀況。所以我們可以使用 mock objects,在 RSpec 裡面叫做 double(替身)。

在 Setup 階段使用「替身」的資料,直接進行測試。

舉例來說,我這裡有一個學生計算器

class StudentsCalculator

  def initialize(course)
    @course = course
  end

  def students_count
    @course.students_count
  end
end

我還沒想好 course.students_count 要怎樣設計(這在 TDD 中很常見),但是我知道在 StudentsCalculator 中的邏輯,吃的就是將來 course 提供的 students_count,而且「我現在就想要驗證這件事」。所以我可以假造一個 course 的替身,讓這段測試可以通過。


require 'rails_helper'

RSpec.describe StudentsCalculator do
  describe "#students_count" do 
    it "returns students count" do 
      course = double(:students_count => 5 )
      student_calculator = StudentsCalculator.new(course)
      expect(student_calculator.students_count).to eq(5)
    end
  end
end

 
4 months ago

以這個程式來說,我們要把「課程上架」,課程上架以後,系統會送一封 onboarding 信給開課教師。

class Course
  belongs_to :user

  def published?
    published_at.present?
  end

  def publish!
    user.send_welcome_email!(self)
    update_column(:published_at, Time.now)
  end

end
class User < ActiveRecord::Base

  has_many :courses    

  def send_welcome_email!(course)
    UserMailer.send_course_welcome(course)
  end
end

但是下面這個測試,我們在這裡測試的狀況,我們根本不在乎「信是否有沒有被送給開課教師」,我們在乎的是:呼叫 publish! 後,是否課程真的已經會被上架。

所以我們就會用 allow(course.user).to receive(:send_welcome_email!)send_welcome_email! 這件事 stub 掉,讓它 return nil,這樣就不會呼叫 UserMailer 了。

何況,我們可能也還沒時間開發 UserMailer 內的東西。

  describe "#publish!" do 

    let(:user) { FactoryGirl.create(:user) }
    let(:course) { FactoryGirl.create(:course, :user => user ) }

    it "will be publsihed" do 
      allow(course.user).to receive(:send_welcome_email!)
      course.publish!
      expect(course).to be_published
    end
  end
  • 備註: 在 RSpec 2.x 版,你可以直接這樣寫 course.stub(:send_welcome_email!),但這寫法造成一些敘述語法問題,所以 RSpec 3 改成 allow + receive
  • 備註: 在 RSpec 2.x 的 stubmock 語法造成一些很大的語法與觀念問題。RSpec 3 改的清楚不少...
 
4 months ago

Stub

一般來說,驗證「回傳值」或驗證「狀態改變時」,經常會使用 Stub 手法。
因為在這兩種狀況中,即便這個 method 有可能去呼叫「外部物件」,坦白來說,我們「不在乎」。


比如說這段程式碼

class Post
  def visit!
    update_visit_cache_to_memory!
    self.increment_counter(:visit_count, 1)
  end

  def current_visit_count
    update_visit_cache_to_memory!
    return visit_count
  end
end

因為我們只在乎「當下這個物件」。所以寫測試時,我們會 stub 掉 update_visit_cache_to_memory!「呼叫 外部 method」這件事。以取得我們要的結果。

Mock

「模擬」與一個「協作者」的互動,設立一個「會收到指定訊息」的期望,去驗證互動是否真的有發生。

 
4 months ago

要開始講解 Stub 與 Mock 這兩個概念之前。我想要先來介紹單元測試的種類,這樣才講得清楚後續要繼續寫下去的主題。

一般來說,單元測試分成三種狀況。

1. 驗證回傳值是否符合期待

查詢:

  • 回傳某些東西
  • 不改變狀態

2. 驗證物件狀態的改變是否符合期待

命令:

  • 改變內部狀態

3. 驗證是否有去執行與外部的呼動

呼叫:

  • 是否有去執行與外部的互動

 
4 months ago

很多新手在經歷一兩年的開發經驗後,開始覺得寫測試很重要。想要入門學習測試。但是看到這些名詞:

  • stub
  • mock
  • double
  • allow
  • receive
  • expect

就覺得很頭痛。特別是 RSpec 2.1 與 RSpec 3 一些語法升級,又造成了更大的混淆。所以我希望寫一系列的文章,解釋清楚這些名詞。想辦法把測試這個主題講清楚。

這一個系列,我會嘗試以以下的順序講解以下主題:

 

宣傳連結

  1. 免費 Rails 學習手冊

    Buy Rails 101
  2. Intro to Growth Hack


    Growth GrowthSchool

    預購 8 折 中