지나친 테스트

Posted by epicdev Archive : 2012. 6. 16. 02:29

도가 지나친 수준으로 테스트에 관심을 갖는 경우도 있다.


  • 테스트를 기능하게 하려고 실제 코드의 가독성을 희생시킨다. 실제 코드 테스트를 가능하게 하는 것은 반드시 윈-윈 상황이 되어야 한다. 하지만 테스트를 가능하게 하려고 실제 코드에 지저분한 코드를 집어넣어야 한다면, 뭔가 잘못된 것이다.
  • 100% 코드 테스트에 집착하는 일. 코드의 90%를 테스트하는 노력이 종종 나머지 10%를 테스트하는 비용보다 적은 노력이 들기도 한다. 그 10%는 어쩌면 버그로 인한 비용이 별로 높지 않기 때문에 굳이 테스트할 필요가 없는 사용자 인터페이스나 이상한 에러 케이스를 포함하고 있을지도 모른다.
  • 사실, 코드를 100% 테스트하는 일은 일어나지 않는다. 테스트되지 않은 버그가 있을 수도 있고 테스트되지 않은 기능이 있을 수도 있으며, 요구사항이 달라졌다는 사실을 모르고 있을 수도 있기 때문 이다.
  • 버그가 야기하는 비용이 어느 정도인지에 따라서, 테스트 코드를 작성하는 시간이 의미를 갖는 부분이 있고 그렇지 않은 부분도 있기 마련이다. 만약 웹사이트의 프로토타입을 만든다면, 테스트 코드 작성 건은 전혀 의미가 없다. 한편 우주선이나 의료장비를 통제하는 프로그램을 작성한다면 아마 테스트 코드에 주된 관심을 쏟아야 할 것이다.
  • 테스트 코드로 실제 제품 개발이 차질을 빚게 되는 일. 우리는 단지 프로젝트의 일부분에 불과한 테스트가 프로젝트 전체를 지배하는 경우를 본 적이 있다. 테스트가 숭배되어야 하는 신의 자리를 차지하고, 프로그래머들은 자신의 시간이 다른 일에 쓰이는 것이 더 낫다는 사실을 망각한 채 자신을 위한 의식과 동작에 몰두한다. 




읽기 좋은 코드가 좋은 코드다

저자
더스틴 보즈웰 지음
출판사
한빛미디어 | 2012-04-06 출간
카테고리
컴퓨터/IT
책소개
이 책은 코드를 작성할 때 언제나 적용할 수 있는 기본적인 원리...
가격비교


  

테스트에 친숙한 개발

Posted by epicdev Archive : 2012. 6. 16. 02:20

테스트하기 어려운 코드의 특징과 이것이 설계와 관련된 문제에 미치는 영향

특징 

테스트 문제 

설계 문제 

전역변수를 사용한다 

테스트할 때마다 모든 전역 변수를 초기화해야 한다. 그렇지 않으면 테스트가 서로의 결과에 영향을 줄 수 있다.

어느 함수가 어떤 부수적인 효과를 가지는지 판별하기 어렵다. 각각의 함수를 별도로 고려할 수 없다. 모든 게 제대로 작동하는지 알려면 프로그램 전체를 생각해야 한다. 

코드가 많은 외부 컴포넌트를 사용한다 

처음에 설정할 일이 너무 많아서 테스트를 작성하기 힘들다. 따라서 테스트를 작성하는 일이 즐겁지 않아 테스트 작성을 회피한다.

이러한 외부 시스템 중에서 어느 하나가 제대로 작동하지 않으면 프로그램이 실패한다. 프로그램에 가한 수정이 어떤 효과를 낳을지 알기 어렵다. 클래스들을 리팩토링하기 어렵다. 시스템이 더 많은 실패 모드와 복구 경로를 가지게 된다. 

코드가 비결정적인(nondeterministic) 행동을 가진다 

테스트가 변덕스럽고 안정적이지 못하다. 가끔 실패하는 테스트가 그냥 무시된다. 

프로그램이 경합 조건이나 재생하기 어려운 버그를 가지고 있을 확률이 높다. 프로그램의 논리를 따라가기가 어렵다. 현장에서 발생한 버그를 추적해서 수정하기가 매우 어렵다.


테스트하기 좋은 코드의 특징

 특징

테스트 장점 

설계 장

클래스들이 내부 상태를 거의 가지고 있지 않다

메소드를 테스트하기 전에 설정할 일이 거의 없고 감추어져 있는 상태가 별로 없기 때문에 테스트 작성이 수월하다.

소수의 내부 상태를 가지는 클래스는 이해하기 더 간단하고 쉽다.

클래스/함수가 한 번에 하나의 일만 수행한다

더 적은 테스트 코드가 요구된다.

더 작고 간단한 컴포넌트는 더 잘 모듈화되어있고, 시스템이 서로 더 멀리 떨어져 있다

클래스가 다른 클래스에 의존하지 않고, 서로 상당히 떨어져 있다

각 클래스가 독립적으로 테스트된다 (여러 클래스를 동시에 테스트할 때에 비해서 훨씬 쉽다) 

시스템이 병렬적으로 개발될 수 있다. 클래스가 쉽게 수정될 수 있고, 혹은 시스템의 나머지 부분에 영향을 주지 않으면서 제거될 수도 있다.

함수들이 간단하고 잘 정의된 인터페이스를 가지고 있다 

테스트 대상이 잘 정의되어 있다. 간단한 인터페이스는 테스트를 위해서 더 적은 일을 요구한다. 

프로그래머가 인터페이스를 쉽게 배울 수 있어 해당 인터페이스는 재사용될 가능성이 더 높다. 




읽기 좋은 코드가 좋은 코드다

저자
더스틴 보즈웰 지음
출판사
한빛미디어 | 2012-04-06 출간
카테고리
컴퓨터/IT
책소개
이 책은 코드를 작성할 때 언제나 적용할 수 있는 기본적인 원리...
가격비교


'Archive' 카테고리의 다른 글

MapReduce  (0) 2012.06.23
지나친 테스트  (0) 2012.06.16
자기 주변에 있는 라이브러리에 친숙해져라  (0) 2012.06.16
변수의 범위를 좁혀라  (0) 2012.06.15
쇼트 서킷 논리 (Short-Circuit Logic) 오용 말기  (0) 2012.06.15
  

다섯가지의 소프트웨어 테스트

Posted by epicdev Archive : 2011. 11. 14. 16:08
큰 개념의 순으로

1. Acceptance testing
2. Stress/load testing
3. Functional testing
4. Integration testing
5. Unit testing


JUnitinAction
카테고리 과학/기술 > 컴퓨터
지은이 Massol (Manning, 2004년)
상세보기
 
  

Unit test와 functional test의 차이점

Posted by epicdev Archive : 2011. 11. 14. 14:09
출처: http://software-testing-zone.blogspot.com/2007/01/unit-testing-versus-functional-tests.html

Unit tests tell a developer that the code is doing things right; functional tests tell a developer that the code is doing the right things.

Unit tests:
Unit tests are written from a programmer's perspective. They ensure that a particular method of a class successfully performs a set of specific tasks. Each test confirms that a method produces the expected output when given a known input.

Writing a suite of maintainable, automated unit tests without a testing framework is virtually impossible. Before you begin, choose a framework that your team agrees upon. You will be using it constantly, so you better like it. There are several unit-testing frameworks available from the Extreme Programming Web site. The one I am most familiar with is JUnit for testing Java code.

Functional tests:
Functional tests are written from a user's perspective. These tests confirm that the system does what users are expecting it to.

Many times the development of a system is likened to the building of a house. While this analogy isn't quite correct, we can extend it for the purposes of understanding the difference between unit and functional tests. Unit testing is analogous to a building inspector visiting a house's construction site. He is focused on the various internal systems of the house, the foundation, framing, electrical, plumbing, and so on. He ensures (tests) that the parts of the house will work correctly and safely, that is, meet the building code. Functional tests in this scenario are analogous to the homeowner visiting this same construction site. He assumes that the internal systems will behave appropriately, that the building inspector is performing his task. The homeowner is focused on what it will be like to live in this house. He is concerned with how the house looks, are the various rooms a comfortable size, does the house fit the family's needs, are the windows in a good spot to catch the morning sun. The homeowner is performing functional tests on the house. He has the user's perspective. The building inspector is performing unit tests on the house. He has the builder's perspective.

Like unit tests, writing a suite of maintainable, automated functional tests without a testing framework is virtually impossible. JUnit is very good at unit testing; however, it unravels when attempting to write functional tests. There is no equivalent of JUnit for functional testing. There are products available for this purpose, but I have never seen these products used in a production environment. If you can't find a testing framework that meets your needs, you'll have to build one.

No matter how clever we are at building the projects we work on, no matter how flexible the systems are that we build, if what we produce isn't usable, we've wasted our time. As a result, functional testing is the most important part of development.

Because both types of tests are necessary, you'll need guidelines for writing them. 
  

소프트웨어를 테스트하라

Posted by epicdev Archive : 2011. 10. 5. 10:52
<실용주의 프로그래머 팁>
소프트웨어를 테스트하라. 그렇지 않으면 사용자가 테스트하게 될 것이다.


실용주의프로그래머
카테고리 컴퓨터/IT > 프로그래밍/언어
지은이 앤드류 헌트 (인사이트, 2007년)
상세보기
 

'Archive' 카테고리의 다른 글

가차 없는 테스트  (0) 2011.10.06
다익스트라의 테스팅 관련 명언  (0) 2011.10.06
테스트하기 쉬운 코드  (0) 2011.10.05
/etc/passwd 파일의 포맷  (0) 2011.10.04
Stop Over-Engineering  (0) 2011.10.04
  

테스트하기 쉬운 코드

Posted by epicdev Archive : 2011. 10. 5. 09:45
테스트 가능성이 높은 코드는 디자인에 좋다. 재미있게도, 디자인을 잘 만들려고 할 때보다 테스트 가능성을 높이려고 했을 때 결과 코드의 디자인이 더 나은 경우가 많다.


실용주의프로그래머
카테고리 컴퓨터/IT > 프로그래밍/언어
지은이 앤드류 헌트 (인사이트, 2007년)
상세보기
 

'Archive' 카테고리의 다른 글

다익스트라의 테스팅 관련 명언  (0) 2011.10.06
소프트웨어를 테스트하라  (0) 2011.10.05
/etc/passwd 파일의 포맷  (0) 2011.10.04
Stop Over-Engineering  (0) 2011.10.04
디자인 패턴 공부 순서  (0) 2011.10.04
  

직교성과 테스트

Posted by epicdev Archive : 2011. 10. 1. 13:24
직교적으로 설계, 구현한 시스템은 테스트하기 더 쉽다. 시스템 컴포넌트 간의 상호작용이 형식화되고 제한되었기 때문에 시스템 테스트의 더 많은 부분을 각각의 모듈 수준에서 수행 할 수 있기 때문이다. 이는 모듈 수준의 테스트가 통합 테스트보다 테스트케이스를 만들고 수행하기 훨씬 쉽다는 점에서 좋은 소식이라고 할 수 있다. 우리는 모든 모듈이 자신만의 단위 테스트를 위한 테스트케이스를 갖고, 테스트가 정규 빌드 과정의 일부로 수행되어야 한다고 생각한다.

단위 테스트를 만든다는 것 자체가 직교성을 테스트 해 볼 수 있는 흥미로운 작업이다. 단위 테스트를 빌드하고 링크하기 위해서는 어떤 작업이 필요한가? 시스템 나머지의 상당 부분을 끌어들여 테스트케이스를 만들고 컴파일 혹은 링크해야 하지는 않는가? 만약 그렇다면 이는 모듈과 시스템의 나머지 부분과의 결합도를 적절히 줄이지 못했다는 증거다.

버그 수정은 시스템의 직교성을 총체적으로 점검 해 볼 수 있는 값진 시간이다. 문제가 발생했다면 버그 수정이 얼마나 지역화 되어 있는지 평가해 보라. 모듈 하나만 변경하면 되는가? 변화가 시스템 전반에 걸쳐 분산되어 있지는 않은가? 수정을 했다면 모든 것이 제대로 고쳐졌는가? 수정이 끝난 후 생각지도 못 했던 곳에서 새로운 문제가 발생하지는 않는가? 만약 그렇다면 자동화에 집중 할 좋은 기회다. 만약 소스코드 관리 시스템을 사용한다면 버그를 수정하고 테스트를 마친 뒤 버그 수정에 대한 태그를 붙여라. 이렇게 하면 각 버그 수정에 의해 영향 받은 소스 파일의 개수에 대해 경향을 분석한 월 단위 리포트를 받아 볼 수 있을 것이다.


실용주의프로그래머
카테고리 컴퓨터/IT > 프로그래밍/언어
지은이 앤드류 헌트 (인사이트, 2007년)
상세보기
 
  
 «이전 1  다음»