<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>기본이 바로 선 나라 &#187; TestCrunch</title>
	<atom:link href="http://dicawoo.com/tag/testcrunch/feed" rel="self" type="application/rss+xml" />
	<link>http://dicawoo.com</link>
	<description>Luck is where preparation meets opportunity.</description>
	<lastBuildDate>Tue, 10 Apr 2012 15:01:14 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.2</generator>
		<item>
		<title>테스트는 누가해야 하는가?를 읽고&#8230;</title>
		<link>http://dicawoo.com/42</link>
		<comments>http://dicawoo.com/42#comments</comments>
		<pubDate>Sun, 03 Feb 2008 15:23:41 +0000</pubDate>
		<dc:creator>정의의소</dc:creator>
				<category><![CDATA[Test]]></category>
		<category><![CDATA[tdd]]></category>
		<category><![CDATA[TestCrunch]]></category>
		<category><![CDATA[테스트]]></category>

		<guid isPermaLink="false">http://kwwoo75.cafe24.com/?p=42</guid>
		<description><![CDATA[TestCrunch에 올라온&#160; &#8220;테스트는 누가해야 하는가?&#8221;에 대한 트랙백을 위한 글 입니다. Nikkei Electronics 2007년 4월 23일 자에 나온 &#8220;공들여 만드는 소프트웨어, 검증하기 쉬운 설계로&#8220;라는 제목의 자료에도 나오는 그림 중에 이런 말이 있습니다. &#8221; 아니 이렇게 테스트하기 어렵게 설계하면 어떻게 해요!&#8221;- 테스터 아직 우리나라 대부분의 업체에서는 테스터가 이렇게 이야기 할 수 있는 곳은 없을 것입니다. &#8220;아니 이렇게 <a href='http://dicawoo.com/42' class='excerpt-more'>[...]</a>
Related posts:<ol>
<li><a href='http://dicawoo.com/7' rel='bookmark' title='테스트에 대한 생각의 변화'>테스트에 대한 생각의 변화</a></li>
<li><a href='http://dicawoo.com/22' rel='bookmark' title='Agile OST 2007'>Agile OST 2007</a></li>
<li><a href='http://dicawoo.com/13' rel='bookmark' title='Test-Driven Development, A Year Later'>Test-Driven Development, A Year Later</a></li>
</ol>]]></description>
			<content:encoded><![CDATA[
<div class="topsy_widget_data topsy_theme_blue" style="float: right;margin-left: 0.75em; background: url(data:,%7B%20%22url%22%3A%20%22http%253A%252F%252Fdicawoo.com%252F42%22%2C%20%22style%22%3A%20%22big%22%2C%20%22title%22%3A%20%22%ED%85%8C%EC%8A%A4%ED%8A%B8%EB%8A%94%20%EB%88%84%EA%B0%80%ED%95%B4%EC%95%BC%20%ED%95%98%EB%8A%94%EA%B0%80%3F%EB%A5%BC%20%EC%9D%BD%EA%B3%A0...%22%20%7D);"></div>
<p><a href="http://testcrunch.kr/blog" target="_blank">TestCrunch</a>에 올라온&nbsp; <a href="http://testcrunch.kr/blog/4" target="_blank">&#8220;테스트는 누가해야 하는가?&#8221;</a>에 대한 트랙백을 위한 글 입니다.</p>
<p>Nikkei Electronics 2007년 4월 23일 자에 나온 <span style="color: rgb(212, 26, 1); font-weight: bold;">&#8220;공들여 만드는 소프트웨어, 검증하기 쉬운 설계로</span>&#8220;라는 제목의 자료에도 나오는 그림 중에 이런 말이 있습니다.</p>
<blockquote><p><span style="font-weight: bold;">&#8221; 아니 이렇게 테스트하기 어렵게 설계하면 어떻게 해요!&#8221;<br />- 테스터<br /></span></p></blockquote>
<p>아직 우리나라 대부분의 업체에서는 테스터가 이렇게 이야기 할 수 있는 곳은 없을 것입니다. </p>
<p><span style="font-weight: bold;"><br />
<blockquote>&#8220;아니 이렇게 생산하기 어렵게 설계하면 어떻게 해요!&#8221;<br />- 생산담당자</p></blockquote>
<p></span>생산하기 힘드니 다시 설계하라는 이야기를 하는 곳은 있을 수도 있을 겁니다.<br />생산을 고려해서 설계를하고 개발하라는 것입니다.</p>
<p>Application/Game 개발자분들은&#8230; 디자이너분들과 이런 이야기 자주 나누지 않습니까?<br />
<blockquote style="font-weight: bold;">&#8220;이런 디자인/컨셉은 개발하기 힘들다&#8230; 당신들이 개발을 안해봐서 그런가 본데&#8230; 이건 너무 힘들어요&#8230;&#8221;<br />- 개발자</p></blockquote>
<p>테스트도 개발의 한 부분이고 중요하다는 것을 개발자가 더 잘 알고 있을 것입니다.<br />그러나 오랜 관습과 바쁘다는 현실에서 변화하기가 쉽지 않은 것 같습니다.</p>
<p>개발자 테스트하면 자주 등장하는 TDD는 테스트보다는 Design적인 측면이 더 중요하게 생각되는 것 같습니다.<br /><span style="color: rgb(0, 0, 255); font-weight: bold;">Test</span> Driven Development 보다는 <span style="color: rgb(255, 0, 0); font-weight: bold;">Design</span>의 의미가 강하다고 생각됩니다.<br />TDD에 의해서 모든 테스트가 끝나지 않습니다. TDD는 품질에 대한 최소한의 요구사항이라고 생각합니다.
<pre style="font-weight: bold;">
<blockquote>“Clean code that works!"- Test Driven Devlopment 에서 Kent Bect</blockquote>
</pre>
<p>TDD는 분석/설계 도구이지 테스트 도구가 아닙니다. TDD를 통해서 얻는 Code Coverage는 TDD의 목적이 아니라고 생각됩니다. 부수적인 이득이라고 봐야겠죠.<br />TDD의 궁극의 목적은 <span style="font-weight: bold; color: rgb(0, 0, 255);">&#8220;Clean Code That Works&#8221;</span>라고 봅니다.</p>
<p><span style="font-weight: bold;">테스트를 위하여 API 뿐만 아니라, 시스템 전체를 고려한 설계와 개발이 이루어지고 함께 테스트가 진행되어야 더욱 빠른 개발을 할 수 있다고 생각합니다.</span></p>

<p>Related posts:<ol>
<li><a href='http://dicawoo.com/7' rel='bookmark' title='테스트에 대한 생각의 변화'>테스트에 대한 생각의 변화</a></li>
<li><a href='http://dicawoo.com/22' rel='bookmark' title='Agile OST 2007'>Agile OST 2007</a></li>
<li><a href='http://dicawoo.com/13' rel='bookmark' title='Test-Driven Development, A Year Later'>Test-Driven Development, A Year Later</a></li>
</ol></p>]]></content:encoded>
			<wfw:commentRss>http://dicawoo.com/42/feed</wfw:commentRss>
		<slash:comments></slash:comments>
		</item>
	</channel>
</rss>

