tag:blogger.com,1999:blog-1298974142445162186.post1518807474622374727..comments2024-03-19T15:58:12.198+08:00Comments on 搞笑談軟工: 無痛將驗收測試文件寫在測試案例中Teddy Chenhttp://www.blogger.com/profile/02066842119056439711noreply@blogger.comBlogger1125tag:blogger.com,1999:blog-1298974142445162186.post-69593373605604106712021-12-24T02:40:07.341+08:002021-12-24T02:40:07.341+08:00想不到還可以再次遇到這個概念,4 年前小弟服務的公司就是導入此作法(工程 team 規模約 50+ ...想不到還可以再次遇到這個概念,4 年前小弟服務的公司就是導入此作法(工程 team 規模約 50+ 人,採用的語言剛好有現成工具可用),寫起來確實是滿爽的,但所需付出的代價不可不慎。<br /><br />我認為規則越多,弄起來就越麻煩(例如較陡的學習曲線、要較多人配合、每次都要多寫一點 code等)。帶來的好處是否能蓋過缺點,則要看企業的階段、專案性質、團隊文化等適不適合。<br /><br />就好比 Cucumber,我相信還是有公司團隊能夠執行的很好,但許多中小企業比起「做好 BDD」、可能更在乎明年的薪水能不能靠這次趕出的新功能賺起來,此時用容易卡關的工具就不是那麼理想。<br /><br />用 Given-When-Than 寫測試案例,我想到的潛在問題主要有兩個:<br /><br />1. 「規則越多,弄起來就越麻煩」的部分<br />2. 因為 DSL 實作不完美 → 受到限制 → 必須搞各種 workaround → 測試案例反而更難閱讀理解、甚至有 false-negative<br /><br />實際上當初主導引入 Given-When-Than 的人,後來就跟我承認,因為這些問題最後也是寫得沒那麼爽了...<br /><br />但我還是覺得,這樣工具沒有絕對的好或不好,要看團隊適不適合。<br />Brucehttps://www.blogger.com/profile/01737115772342403195noreply@blogger.com