<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" 
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
<title>敏捷方法實務研討會會後筆記4 - 測試驅動開發與工作時程</title>
<link>http://blog.roodo.com/rocksaying/archives/3508885.html/</link>
<description><![CDATA[Tags: 軟體工程 agile_method oop unit_test tdd

測試驅動開發 (Test Driven Development, TDD) 的觀念由來以久。寫程式時會順便寫測試碼，幾乎是所有有經驗的程序員在不自覺下養成的習慣。例如我在《運用訊息溝通網絡及軟體工程方法建立開放源碼專案之個人淺見》一文中，提到我以前用 C 語言寫程式時順手寫測試碼的習慣。不過那個時候，xUnit 這類測試工具還不普遍。當時看其他人寫的開放源碼程式，幾乎是人人各有一套測試碼的撰寫風格。但是隨著 xUnit 工具的普及，測試碼的撰寫方式也愈來愈一致了。同時，也改變了程序員編程時的習慣，帶動了先寫測試碼的「測試驅動開發」觀念。


TDD 的好處，基本用不著我多加說明。 Robert C. Martin 在《敏捷軟體開發-原則、樣式及實務》中寫的再明白不過了。儘管如此，在研討會中，我還是針對 TDD 提了一個問題。我的問題是：能不能藉由測試案例建立更準確的工作時程量測指標，以便掌握確切的工作時程。

]]>
	</description>
<language>zh-tw</language>
<generator>Roodo Blog System</generator>
<copyright>All Rights Reserved</copyright>
<atom:link href="http://blog.roodo.com/rocksaying/archives/3508885-comment.xml" rel="self" type="application/rss+xml" />
<item>
	<title>回應：敏捷方法實務研討會會後筆記4 - 測試驅動開發與工作時程</title>
	<description><![CDATA[看到石頭大哥說自己一個人作TDD，就印證了我之前的假設．我之前猜想在我的公司，應該沒人懂Test，沒人親手寫過，開會就是嘴泡大戰．

這個問題又要回歸到石頭大哥之前寫的台灣嚴重缺乏資深軟體工程師，所以開會常常是一些紙上談兵，或是在迷霧中誤用很多概念，不管是CMMI,agile,TDD很多都是做做表面，喊口號用的．很少人去探究為何這樣做，光探就這些原理，還有很多技術，這樣的磨練就少說都要四到五年，而大部分的人又都認為不幹黑手，想要混個幾年就跳過．]]>
	</description>
	<link>http://blog.roodo.com/rocksaying/archives/3508885.html</link>
	<guid>http://blog.roodo.com/rocksaying/archives/3508885.html#comment-11008745</guid>
		<category>文章回應</category>
	<pubDate>Fri, 22 Jun 2007 19:55:22 +0800</pubDate>
</item>
</channel>
</rss>