단위 테스트를하지 않는 것이 적절한시기는 언제입니까?


138

저는 소규모 회사에서 솔로 개발자로 일하고 있습니다. 저는 회사에서 유일하게 개발자입니다. 정기적으로 작성하고 유지 관리하는 여러 개의 (상대적으로) 대규모 프로젝트가 있으며 그 중 어느 것도 프로젝트를 지원할 테스트가 없습니다. 새로운 프로젝트를 시작할 때 종종 TDD 방식을 시도해야하는지 궁금합니다. 좋은 생각처럼 들리지만 솔직히 관련된 추가 작업을 정당화 할 수는 없습니다.

나는 내 디자인에서 앞으로 생각하기 위해 열심히 노력합니다. 확실히 언젠가 다른 개발자가 내 코드를 유지 관리하거나 최소한 문제를 해결해야한다는 것을 알고 있습니다. 가능한 한 단순하게 유지하고 파악하기 어려운 사항에 대해서는 언급하고 문서화합니다. 사실이 프로젝트는 규모가 크거나 복잡하지 않기 때문에 괜찮은 개발자가 이해하기 힘들다.

테스트에서 본 많은 예제는 코드의 모든 측면을 다루면서 축소되어 있습니다. 나는 유일한 개발자이고 전체 프로젝트의 코드에 매우 가깝기 때문에 쓰기 후 수동 테스트 패턴을 따르는 것이 훨씬 효율적입니다. 또한 테스트를 유지 관리하면 프로젝트에 상당한 양의 드래그가 추가 될 정도로 요구 사항과 기능이 자주 변경되는 것을 발견했습니다. 그렇지 않으면 비즈니스 요구를 해결하는 데 소비 할 수있는 시간입니다.

그래서 매번 같은 결론을 내립니다. 투자 수익률이 너무 낮습니다.

고용 일 기준으로 누군가가 회사에 몇 년간 있었는지 계산하는 것과 같이 알고리즘을 올바르게 작성했는지 확인하기 위해 때때로 몇 가지 테스트를 설정했습니다. 그러나 코드 범위 관점에서 코드의 약 1 %를 다루었습니다.

내 상황에서 여전히 단위 테스트를 정기적으로 수행하는 방법을 찾습니까, 아니면 그 오버 헤드를 피하는 것이 정당합니까?

업데이트 : 내 상황에 대해 몇 가지 제외했습니다. 프로젝트는 모두 웹 응용 프로그램입니다. 모든 코드를 다루려면 자동화 된 UI 테스트를 사용해야하는데, 이는 여전히 수동 테스트보다 큰 이점이없는 영역입니다.


1
모두 감사합니다. 나는 여기서 많이 배우고 있습니다. 내 상황에 대한 몇 가지 사항 : 프로젝트는 모두 웹 응용 프로그램입니다. 모든 코드를 다루려면 자동화 된 UI 테스트를 사용해야하는데, 이는 여전히 수동 테스트에 비해 큰 이점이없는 영역입니다.
Ken Pespisa

1
Telerik의 웹 자동화 테스트 도구를 사용하여 Transactis에서 큰 성공을 거두었습니다. 우리는 이미 수십 가지의 이전 수동 브라우저 테스트를 자동화로 전환했습니다. 자동 테스트는 더 빠르며 웹 사이트의 성능 문제를 강조하는데도 좋습니다.
John Kaster

2
완전한 웹 페이지에 대한 자동 브라우저 테스트를 시도한 프로젝트를 보았습니다. 내가 알 수있는 한, 수동 테스트를 통해 발견 된 수백 가지의 심각한 버그는 발견하지 못했으며 개발 및 유지 보수에 막대한 시간이 소요되었습니다. (NUnit이 구동하는 셀레늄 사용). 게다가 브라우저와 테스트 프레임 워크의 비 호환성으로 인해 일부 테스트는 문제가 아닌 경우 자주 중단됩니다.
O'Rooney

1
이것은 실제로 해답이 아니라 관찰입니다. "요구 사항이 너무 자주 변하기 때문에"단위 테스팅에 대한 당신의 주장은 내가 일하는 곳에서 듣는 반대 주장을 상기시켜줍니다. 어쨌든 거의 변하지 않습니다! " ;)
Bane

2
웹 응용 프로그램의 자동화 된 UI 테스트는 단위 테스트가 아니며, 모두 다른 짐승이며 원치 않으면 당신을 비난하지 않을 것입니다. 그러나 모든 비즈니스 코드는 백엔드에 있어야하며 테스트해야합니다.
Nyamiou Galeanthrope

답변:


84

테스트에서 본 많은 예제는 코드의 모든 측면을 다루면서 축소되어 있습니다.

그래서? 모든 것을 테스트 할 필요는 없습니다 . 관련있는 것들.

나는 유일한 개발자이고 전체 프로젝트의 코드에 매우 가깝기 때문에 쓰기 후 수동 테스트 패턴을 따르는 것이 훨씬 효율적입니다.

사실은 거짓입니다. 더 효율적이지 않습니다. 정말 습관 일뿐입니다.

다른 솔로 개발자가하는 일은 스케치 또는 개요를 작성하고 테스트 사례를 작성한 다음 개요를 최종 코드로 채우는 것입니다.

매우 효율적입니다.

또한 테스트를 유지 관리하면 프로젝트에 상당한 양의 드래그가 추가 될 정도로 요구 사항과 기능이 자주 변경되는 것을 발견했습니다.

또한 거짓입니다. 테스트는 드래그가 아닙니다. 요구 사항 변경은 드래그입니다.

요구 사항을 반영하려면 테스트를 수정해야합니다. 그들의 소량 또는 높은 수준; 처음에 쓰거나 마지막에 쓰십시오.

테스트가 통과 될 때까지 코드는 수행되지 않습니다. 이것이 소프트웨어의 보편적 인 진실입니다.

"여기있는 곳"수용 테스트를 제한 할 수 있습니다.

또는 단위 테스트를 수행 할 수 있습니다.

또는 둘 다 가질 수 있습니다.

그러나 무엇을 하든지 항상 소프트웨어가 작동하는지 테스트하는 테스트가 있습니다.

약간의 형식 성과 멋진 단위 테스트 도구 모음을 사용하면 테스트가 훨씬 유용합니다.


8
나는 당신의 첫 번째 진술을 좋아합니다. 수동 대 단위 테스트의 효율성과 관련하여, 나는 나의 진술이 완전히 거짓이거나 당신의 진술이 완전히 사실이라고 믿지 않습니다. 최대 효율을 달성하기 위해 자동 테스트와 수동 테스트 사이에 균형이있는 것 같습니다.
Ken Pespisa

9
@ 켄 페스 피사 : 죄송합니다. 나는 약 2 년 전 (30 년 동안 테스트를 마친 후) TDD 쿨 에이드를 마셨다. 이제 테스트 우선입니다. 건축 할 때 할 생각이 적기 때문에 훨씬 더 생산적으로 만들었습니다.
S.Lott

3
@ Ken Pespisa : 아니요. 답변에 균형이 있습니다. 0으로 나누는 것이 옳은지 물었다면 어떤 이유로 든 한 방향으로 기울어지는 압도적 인 반응이 나타납니다. sqrt(-1)정수 여야하는지 물으면 한 방향으로 기대어 압도적 인 반응을 얻게됩니다. 균형은 "어떻게"와 "어떤 순서"입니다. 사실은 테스트 해야 한다는 것입니다 . 먼저 테스트를 작성하고 작동하는지 확인하십시오.
S.Lott

21
구현 세부 사항이 아닌 인터페이스 테스트를 고려하십시오. 한계 및 경계 사례를 테스트하십시오. 위험한 코드를 테스트하십시오. 코드를 검사하는 것은 다른 사람의 코드를 검사하는 것보다 오류가 발생하기 쉽지만 많은 코드는 검사로 확인할만큼 간단합니다. 최초의 수동 테스트가 10 번의 자동화 테스트보다 훨씬 효율적일 수 있습니다.
BillThor

10
"테스트가 통과 될 때까지 코드는 수행되지 않습니다"-실제로는 아닙니다. IMO. 테스트를 통과하면 코드 가 시작 됩니다. 코드는 1 년 또는 2 년 동안 가동 될 때까지 수행되지 않으며, 크고 적극적이며 초조 한 사용자 기반의 스트레스 테스트 및 통합 테스트를 받아야합니다. 이것이 실제로 중요한 유일한 테스트입니다.
벡터

107

eyeblink에서 실행할 수 있고 녹색 또는 빨간색 표시등을 켤 수있는 일련의 테스트가 있다고 상상해보십시오. 이 일련의 테스트가 모든 것을 테스트했다고 상상해보십시오 ! 테스트 스위트를 실행하기 위해 ^ T를 입력하기 만하면된다고 상상해보십시오. 이것이 당신에게 어떤 힘을 줄 것입니까?

무언가를 깨뜨릴 염려없이 코드를 변경할 수 있습니까? 기존 기능을 중단 할 염려없이 새로운 기능을 추가 할 수 있습니까? 손상을 두려워하지 않고 지저분한 코드를 빠르게 정리할 수 있습니까?

예, 모든 것을 할 수 있습니다! 그리고 시간이 지남에 따라 코드는 어떻게됩니까? 청소할 위험이 없기 때문에 깨끗하고 깨끗합니다.

어깨에 작은 요정이 있다고 상상해 봅시다. 코드 라인을 작성할 때마다 요정은 테스트 라인에 해당 코드 라인이 의도 한 기능을 수행했는지 테스트 한 무언가를 추가합니다. 따라서 매 2 초마다 ^ T를 누르고 마지막으로 작성한 코드가 작동하는지 확인할 수 있습니다.

얼마나 많은 디버깅을 할 것이라고 생각하십니까?

이것이 환상처럼 들리면 옳습니다. 그러나 현실은 크게 다르지 않습니다. eyeblink를 몇 초로 바꾸고 요정은 TDD 규율로 바꾸십시오.

1 년 전에 구축 한 시스템으로 돌아오고 중앙 객체 중 하나를 만드는 방법을 잊었다 고 가정 해 봅시다. 개체를 만들 수있는 모든 방법으로 테스트하는 테스트가 있습니다. 당신은 그 테스트를 읽고 당신의 기억을 조깅 할 수 있습니다. API를 호출해야합니까? 호출 할 수있는 모든 방법으로 해당 API를 호출하는 테스트가 있습니다. 이 테스트는 이해하기 쉬운 언어로 작성된 작은 문서 입니다. 그들은 완전히 모호하지 않습니다. 그들은 너무 형식적이어서 그들이 처형합니다. 그리고 그들은 응용 프로그램과 동기화 할 수 없습니다!

투자 가치가 없습니까? 당신은 나를 놀 리고있어! 어떻게 그 테스트 모음을 원하지 않을 수 있습니까? 자신에게 호의를 베풀고 어리 석음에 대한 불만을 멈추십시오. TDD를 잘하는 법을 배우고 얼마나 빨리 가고 코드가 얼마나 깨끗한 지 살펴보십시오.


28
와우, 밥 아저씨? 당신의 생각을 여기서 얻는 것이 좋습니다. 나는 TDD의 이점에 대해 당신에게 동의합니다. 실제로 거기에는 논쟁의 여지가 없습니다. 문제는 시간 투자와 ROI에 관한 것입니다. 이런 것들을 고려하는 것은 어리석지 않습니다. 프로젝트가없는 경우보다 TDD를 완료하는 데 50 % 더 많은 시간이 걸리고 요정은 프로젝트 수명 기간 동안 수동 테스트보다 10 % 만 시간을 절약 할 수 있다고 말합니다. 그것은 환상처럼 보일지 모르지만, 특정 프로젝트에서는 전적으로 그럴듯하다고 생각합니다.
켄 페스 피사

11
@Ken "프로젝트가없는 것보다 TDD를 마치는 데 50 % 더 많은 시간이 걸린다고 상상해보십시오." 저에게는 환상처럼 들립니다. 사실, 당신이 그것을 뒷받침 할 증거가 없어도 그 자리에서 그 그림을 찾은 것처럼 들립니다.
Rein Henrichs

18
@Rein Henrichs-물론 숫자를 만들었습니다. 이것은 가상의 진술이었습니다. 나는 TDD가 프로젝트에 상당한 시간을 추가한다는 점을 지적하고 있으며, 대가로 동등한 가치를 제공 할 것인지 고려해야한다. TDD의 가치에 대해 설득 할 필요는 없습니다. 그러나 만병 통치약은 아닙니다.
Ken Pespisa

11
@Rein, "사용 가능한 증거"란 정확히 무엇입니까? 정교하게 작성하십시오.
Ken Pespisa

22
@Uncle Bob "몇 초 후 아이브 링크를 교체하십시오": 물론 농담입니다. TDD는 좋은 도구이지만 관련 부품 만 테스트해야합니다. 그렇지 않으면 심각한 개발보다 테스트 유지 관리에 더 많은 시간을 할애 할 수 있습니다. 요구 사항이 매우 빠르게 변경 될 때 특히 그렇습니다. 항상 변경되는 클래스에 대한 테스트를 지속적으로 작성하고 버립니다. 나는 TDD가 나쁘지 않다는 것을 말하지 않고, 현명하게 사용해야하며 제안한 것처럼 기계적으로 적용해서는 안됩니다.
Giorgio

34

실수는 테스트를 즉각적인 수익없이 시간 투자로 보는 것입니다. 반드시 그런 식으로 작동하지는 않습니다.

먼저 테스트를 작성하는 것은 정말 코드의이 부분은 할 필요가 무엇에 당신을 집중한다.

두 번째로 실행하면 테스트에서 발생할 수있는 버그가 드러납니다.

세 번째로 실행하면 때로는 테스트에서 나타나지 않는 버그가 나타나고 실제로 프로덕션에서 엉덩이를 물게됩니다.

넷째, 실행중인 시스템에서 버그를 발견하고 이에 대한 단위 테스트를 작성하면 나중에 해당 버그를 다시 소개 할 수 없습니다. 정말 큰 도움이 될 수 있습니다. 다시 도입 된 버그는 일반적이며 매우 성가시다.

다섯째, 다른 사람에게 코드를 넘겨야하는 경우 테스트 스위트를 사용하면 훨씬 쉽게 생활 할 수 있습니다. 또한 프로젝트를 무시하고 몇 년 후에 프로젝트를 다시 시작한 경우 더 이상 프로젝트에 가까이 있지 않으므로 도움이 될 것입니다.

필자의 경험은 프로젝트 개발 전반에 걸쳐 적절한 단위 테스트를 통해 프로세스가 항상 더 빠르고 안정적으로 이루어 졌다는 것입니다.


2
@Ken, 테스트 스위트는 실행 가능한 형식의 사양입니다.

32

JUnit (Java Unit 테스트 프레임 워크)의 사람들은 테스트 하기가 너무 단순하면 테스트하지 말라는 철학을 가지고 있습니다 . 실용적이기 때문에 모범 사례 FAQ를 읽는 것이 좋습니다 .

TDD는 소프트웨어를 작성하는 다른 프로세스입니다. 단위 테스트의 기본 전제는 디버거가 코드를 단계별로 처리하는 데 시간을 덜 소비하고 코드 변경이 실수로 시스템의 다른 부분을 손상시키는 지 더 빨리 알아낼 수 있다는 것입니다. 그것은 TDD와 맞습니다. TDD주기는 다음과 같습니다.

  1. 테스트 작성
  2. 실패하는 것을 지켜보십시오 (당신이 할 일이 있음을 증명하십시오)
  3. 시험에 합격하는 데 필요한 것을 더 이상 쓰지 마십시오.
  4. 통과하는 것을 지켜보십시오 (예!)
  5. 리팩터링
  6. 세척, 헹굼 및 반복

TDD를 적용 할 덜 분명한 것은 쓰기 코드의 방식을 변경 한다는 입니다. 코드가 작동하는지 테스트 / 확인하는 방법에 대해 스스로 생각하게함으로써 테스트 가능한 코드를 작성하게됩니다. 우리는 단위 테스트에 대해 이야기하기 때문에 일반적으로 코드가 더 모듈화됩니다. 나에게 모듈 식이고 테스트 가능한 코드는 큰 승리입니다.

이제 C # 속성과 같은 것을 테스트해야합니까? 다음과 같이 정의 된 속성을 상상해보십시오.

bool IsWorthTesting {get; set;}

대답은 "아니오"입니다.이 시점에서 언어 기능을 테스트하기 때문에 테스트 할 가치가 없습니다. C # 플랫폼 사용자가 올바르게 이해했다고 믿기 만하면됩니다. 그것이 실패하면 게다가, 무엇을 할 수 당신은 그것을 해결하기 위해 무엇입니까?

또한 코드의 특정 부분이 제대로 테스트하기에는 너무 많은 노력이 필요하다는 것을 알 수 있습니다. 즉, 그렇게하지는 않지만 까다로운 문제에서 사용하거나 사용하는 코드를 테스트해야합니다.

  • 설치가 잘못되었을 때만 발생할 수있는 확인 된 예외. 자바에는 많은 것들이 있습니다. 설치된 파일을 해킹하지 않고 실패 할 수있는 방법이없는 경우에도 catch 블록을 작성하거나 확인 된 예외를 선언해야합니다.
  • 사용자 인터페이스. 테스트중인 컨트롤을 찾고 사용자의 동작을 시뮬레이션하기 위해 올바른 이벤트를 호출하는 것은 매우 번거롭고 경우에 따라 불가능합니다. 그러나 모델 /보기 / 컨트롤러 패턴을 사용하는 경우 모델 및 컨트롤러를 테스트하고 뷰 파트를 수동 테스트로 남겨 둘 수 있습니다.
  • 클라이언트 / 서버 상호 작용 이것은 더 이상 단위 테스트가 아니며 이제 통합 테스트입니다. 유선으로 메시지를주고받는 데 필요한 모든 부분을 쓰되 실제로는 통과하지 마십시오. 좋은 접근 방법은 실제로 유선 통신을 통해 원시 통신과 통신하는 코드의 책임을 줄이는 것입니다. 단위 테스트 코드에서 통신 오브젝트를 모의하여 서비스가 예상대로 작동하는지 확인하십시오.

믿거 나 말거나, TDD는 지속 가능한 개발 속도에 빠질 수 있도록 도와줍니다. 그것은 마술 때문이 아니라 피드백 루프가 빡빡해서 정말 멍청한 실수를 빨리 잡을 수 있기 때문입니다. 작은 실수는 결코 큰 실수로 자라지 않기 때문에 이러한 실수를 수정하는 비용은 본질적으로 일정합니다 (적어도 계획 목적에 충분합니다). 코드 폭주 / 디버그 퍼지 스프린트의 폭발적인 특성과 비교해보십시오.


24

테스트 비용과 버그 비용의 균형을 유지해야합니다.

실패가 "파일을 찾을 수 없음"인 파일을 여는 함수에 대해 10 라인 단위 테스트를 작성하는 것은 의미가 없습니다.

복잡한 데이터 구조에 복잡한 작업을 수행하는 함수 – 분명히 그렇습니다.

까다로운 비트는 중간에 있습니다. 그러나 단위 테스트의 실제 가치는 특정 기능을 테스트하는 것이 아니라 이들 간의 까다로운 상호 작용을 테스트하는 것임을 기억하십시오. 따라서 1 비트 코드의 변화가 1000 줄 떨어진 다른 모듈에서 일부 기능을 중단한다는 점을 발견하는 단위 테스트는 커피의 무게가 가치가 있습니다.


23

테스트는 도박입니다.

테스트 작성은 유닛에서 발생하는 버그 비용과 해당 테스트에서 버그를 발견하지 못하고 (현재 모든 향후 코드 개정 중에) 테스트 개발 비용보다 큰 내기입니다. 이러한 테스트 개발 비용에는 테스트 엔지니어링 추가, 출시 시간 단축, 다른 코드를 코딩하지 않아 발생하는 기회 비용 손실 등의 비용이 포함됩니다.

어떤 내기처럼, 때때로 당신은 이기고 때로는 잃습니다.

버그가 훨씬 적은 최신 소프트웨어가 시장에 출시되는 빠르지 만 버그가 많은 것들보다 우세합니다. 때로는 반대입니다. 특정 분야의 통계와 얼마나 많은 경영진이 도박을하고 싶은지 살펴 봐야합니다.

일부 유형의 버그는 추가적인 특정 테스트를 생성 할 시간이 통계적으로 가치가 없기 때문에 조기에 완료되지 않았거나 조기 온 전성 테스트에서 제외 될 수 있습니다. 그러나 때로는 버그 비용이 너무 커서 (의료, 핵 등) 회사가 잃는 내기를해야합니다 (보험 구매와 유사). 많은 앱은 실패 비용이 높지 않으므로 경제적이지 않은 높은 보험 적용 범위가 필요하지 않습니다. 다른 사람들도 그렇습니다.


3
좋은 대답입니다. 내 원래 질문에 실제로 대답하는 몇 안되는 사람 중 하나입니다. 나는이 글을 쓴 이후 테스팅 세계에 빠져 들었다 (나는 그것을 좋아한다). 나는 그것을 언제 사용해야하는지 알기 전에 더 이해해야한다. 여기에 언급 된 많은 이유 때문에 항상 사용하는 것이 좋습니다. 그러나 결국 그것은 내가 얻는 속도에 달려 있습니다. 결국 그것은 내 회사 / 고객의 통제하에있는 내 시간의 도박이며 종종 프로젝트 삼각형의 맨 아래 모서리에 초점을 맞추기 때문 입니다. wikipedia.org/wiki/Project_triangle
켄 페스 피사

10

내 조언은 제대로 작동하려는 코드 만 테스트하는 것입니다.

버그가있는 코드를 테스트하지 말고 문제가 발생하지 않도록하십시오.


9
내 치과 의사의 말을 상기시켜줍니다. 모든 치아를 치실 필요는 없으며 유지하려는 치아 만 치실 필요가 있습니다.
Ken Pespisa

나는 그것이 내가 그것을 생각하게 한 것이라고 고백한다. ;-)
Nick Hodges

8

나는 종종 TDD 접근법을 시도 해야하는지 궁금합니다. 좋은 생각처럼 들리지만 솔직히 관련된 추가 작업을 정당화 할 수는 없습니다.

TDD와 단위 테스트는 동일하지 않습니다.

코드를 작성한 다음 나중에 단위 테스트를 추가 할 수 있습니다. 그것은 TDD가 아니며 많은 추가 작업입니다.

TDD는 Red Light 루프에서 코딩하는 방법입니다. 초록불. 리팩토링 반복.

이는 아직 존재하지 않는 코드에 대한 테스트를 작성하고, 테스트 실패를보고, 테스트를 수행하도록 코드를 수정 한 다음 코드를 "올바르게"만드는 것을 의미합니다. 이것은 종종 작업을 저장합니다

TDD의 장점 중 하나는 사소한 일에 대한 생각이 줄어든다는 것입니다. 일대일 오류와 같은 것은 사라집니다. 반환되는 목록이 0 또는 1에서 시작하는지 확인하기 위해 API 설명서를 탐색하지 않아도됩니다.


일대일 오류가 사라지는 방법에 대해 자세히 설명해 주시겠습니까? 설명서를 검색하는 것보다 테스트를 통해 배열의 인덱스가 0부터 시작하는지 또는 1부터 시작하는지에 대한 답변을 더 빨리 얻을 수 있다고 말씀하십니까? 나에게는 가능성이 없어 보인다-나는 구글에서 꽤 빠르다 :)
Ken Pespisa

1
실제로 TDD를 작성하면 API (레거시 코드베이스를 포함하여 기능을 문서화 할 목적으로)를 탐색 할 수있는 훌륭한 방법입니다.
Frank Shearar

API가 바뀌면 매우 유용합니다 ... 갑자기 실패한 테스트가 있습니다 :-)
bitsoflogic

@ Ken Pespisa, 확실히 빠릅니다. 0 또는 1이라고 생각하는지 여부에 따라 코드를 작성하고 실행하고 필요한 경우 수정하십시오. 대부분의 경우, 당신은 옳을 것이고 그것을 찾지 않아도되었을 것입니다. 만약 당신이 틀렸다면 10 초 안에 알게됩니다.
Paul Butcher

매우 흥미로운 혜택. 나는 그런 종류의.
Ken Pespisa

3

거의 모든 것을 테스트 한 시스템에서 작업했습니다. 테스트에서 주목할만한 실행은 PDF 및 XLS 출력 코드였습니다.

왜? 데이터를 수집 한 부품을 테스트하고 출력을 작성하는 데 사용 된 모델을 작성할 수있었습니다. 또한 모델의 어떤 부분이 PDF 파일로 이동하는지 파악한 부분을 테스트 할 수있었습니다. PDF가 완전히 주관적 이었기 때문에 PDF가 정상으로 보이는지 테스트 할 수 없었습니다. PDF의 모든 부분 이 주관적이기 때문에 일반 사용자 가 읽을 수 있는지 테스트 할 수 없었습니다 . 또는 막 대형 차트와 원형 차트 중 하나를 선택하여 데이터 집합에 올바른지 확인하십시오.

출력이 주관적 일 경우, 노력할만한 가치가있는 것을 수행 할 수있는 단위 테스트가 거의 없습니다.


실제로 이런 종류의 테스트는 아마도 "통합 테스트"일 것입니다. 그렇습니다. 통합 테스트는 단위 테스트보다 훨씬 어렵습니다. 한 가지 이유는 때때로 "올바른"규칙이 매우 복잡하거나 주관적이라는 것입니다.
sleske

2

많은 경우, '쓰기 후 수동 테스트'는 몇 가지 테스트를 작성하는 것보다 시간이 많이 걸리지 않습니다. 시간을 절약하면 언제든지 해당 테스트를 다시 실행할 수 있습니다.

당신이 (코드 커버리지와 혼동되지 않음) 테스트를 몇 가지 괜찮은 기능 범위가있는 경우, 그리고의 당신은 10 개 기능을 가지고 가정 해 봅시다 - 버튼을 클릭하면 당신이 대략 10 의미 : 그것을 생각 통 더 다시하고 테스트를 ... 앉아서 커피를 마시 며

당신은 또한하지 않는 minutae을 테스트 할 수 있습니다. 중요한 세부 정보를보고 싶지 않다면 기능을 다루는 통합 테스트를 작성할 수 있습니다. IMO, 일부 단위 테스트는 코드가 아닌 언어 및 플랫폼을 너무 세밀하게 테스트합니다.

TL; DR 이점이 너무 좋기 때문에 결코 적절 하지 않습니다 .


2

내가 만난 두 가지 좋은 답변은 다음과 같습니다.

  1. 단위 테스트시기와 수동 테스트시기
  2. 단위 테스트와 관련하여 테스트하지 않아도되는 것은 무엇입니까?

인식 된 오버 헤드를 피하기위한 정당화 :

  • 회사의 즉각적인 시간 / 비용 절감
  • 퇴근 후에도 장기적으로 문제 해결 / 유지 보수 / 확장에있어 잠재적 인 시간 / 비용 절감.

당신은 당신의 작업 품질의 증거로 당신의 측면에서 훌륭한 제품을 남기고 싶지 않습니까? 이기적인 용어로 말하면 당신이하는 것이 낫지 않습니까?


1
끝에 좋은 질문입니다. 나는 내 일에 자부심을 가지고 절대적으로 내 응용 프로그램이 매우 잘 작동합니다 (대담한 경우). 그러나 당신 말이 맞습니다-일부 테스트의 지원으로 더 나아질 수 있습니다. 필자가 여기서 취한 것은 코드 작업에 너무 집착하지 않고 프로젝트에서 작업해야하는 시간 내에 가능한 많은 유용한 테스트를 수행하는 것입니다.
Ken Pespisa

1

전문 개발자는 장기적으로 시간이 절약되므로 단위 테스트를 작성합니다. 코드를 조만간 테스트 할 예정이며, 사용자가하지 않을 경우, 나중에 버그를 수정해야하는 경우 수정하기가 더 어려워지고 효과가 더 많이 나타납니다.

테스트없이 코드를 작성하고 버그가 없다면 괜찮습니다. 나는 버그가 전혀없는 사소한 시스템을 작성할 수 있다고 생각하지 않기 때문에 한 가지 방법으로 테스트한다고 가정합니다.

이전 코드를 수정하거나 리팩토링 할 때 회귀를 방지하기 위해 단위 테스트도 중요합니다. 변경 사항이 이전 코드를 위반 하지 않았다는 것을 입증 하지는 않지만 (물론 :) :)

돌아가서 이미 제공 한 코드에 대한 전체 테스트를 작성하지는 않지만 다음에 기능을 수정해야 할 때 해당 모듈 또는 클래스에 대한 테스트를 작성하려고 시도하면 범위를 최대 70 %까지 얻을 수 있습니다. + 변경 사항을 적용하기 전에 + 도움이되는지 확인하십시오.

당신이 그것을 시도하고 정직하게 말하면 도움이 충분하지 않다고 말할 수는 있지만, 접근 방식을 시험하는 동안 적어도 당신의 가치를 얻는 데 도움이된다는 업계 증거가 충분하다고 생각합니다.


나는 회귀를 막고 자신감을 더하는 것에 대한 생각을 좋아한다. 이것이 바로 테스트를 추가하려는 이유입니다.
Ken Pespisa

1

TDD에 대한 질문은 아니지만 일반적으로 단위 테스트에 대한 질문이지만 대부분의 답변은 pro-TDD 인 것 같습니다.

단위 테스트 또는 단위 테스트 대상에 대한 객관적인 규칙은 없습니다. 그러나 많은 프로그래머들이 단위 테스트를하지 않는 것처럼 보이는 경우가 몇 가지 있습니다.

  1. 개인 방법

OOP 철학에 따라 공용 메소드에서 복잡한 루틴을 분리하는 개인용 메소드를 작성할 수 있습니다. 공용 메소드는 일반적으로 여러 곳에서 호출되어 자주 사용되며, 전용 메소드는 클래스 또는 모듈에서 하나 또는 두 개의 공용 메소드에 의해서만 호출되어 매우 구체적인 것입니다. 일반적으로 퍼블릭 메소드에 대한 단위 테스트를 작성하는 것으로 충분하지만 일부 마법을 일으키는 기본 프라이빗 메소드는 아닙니다. 개인용 메소드에 문제가있는 경우 공용 메소드 단위 테스트는 이러한 문제를 감지하기에 충분해야합니다.

  1. 이미 알고있는 것 (또는 다른 사람이 테스트 한 것)

많은 새로운 프로그래머들이 처음으로 테스트하는 법을 배울 때 이에 반대하고 실행되는 모든 라인을 테스트해야한다고 생각합니다. 외부 라이브러리를 사용하고 있으며 해당 기능을 작성자가 잘 테스트하고 문서화 한 경우 일반적으로 단위 테스트에서 특정 기능을 테스트하는 것은 의미가 없습니다. 예를 들어 누군가 자신의 ActiveRecord 모델이 데이터베이스에 대한 "before_save"콜백이있는 속성에 대한 올바른 값을 유지하는지 테스트하기 위해 테스트를 작성할 수 있습니다. 해당 동작 자체는 이미 Rails에서 철저히 테스트되었습니다. 콜백이 호출하고 있지만 콜백 동작 자체가 아닌 메소드입니다. 가져온 라이브러리의 기본 문제는 단위 테스트가 아닌 승인 테스트를 통해 더 잘 드러납니다.

TDD를하든하지 않든 두 가지 모두 적용 할 수 있습니다.


0

켄, 저와 다른 많은 개발자들이 우리 경력 전반에 걸쳐 당신과 같은 결론에 도달했습니다.

내가 찾을 것이라고 믿는 사실은 (다른 많은 사람들과 마찬가지로) 응용 프로그램에 대한 테스트 작성에 대한 초기 투자가 어려워 보일 수 있지만 올바르게 작성되고 코드의 올바른 부분을 대상으로하면 실제로 톤을 절약 할 수 있다는 것입니다 시간.

내 큰 문제는 사용 가능한 테스트 프레임 워크에 관한 것이었다. 나는 그들이 내가 찾던 것 같은 느낌이 들지 않았으므로 아주 간단한 해결책을 내놓았습니다. 그것은 회귀 테스트의 "어두운면"으로 나를 안내하는 데 정말로 도움이되었습니다. 여기서 내가 한 일에 대한 기본적인 의사 스 니펫을 공유하고 나에게 맞는 솔루션을 찾을 수 있기를 바랍니다.

public interface ITest {
    public string Name {
        get;
    }
    public string Description {
        get;
    }
    public List<ITest> SubTests {
        get;
    }
    public TestResult Execute();
}

public class TestResult {
    public bool Succesful {
        get;
        set;
    }

    public string ResultMessage {
        get;
        set;
    }

    private Dictionary<ITest, TestResult> subTestResults = new Dictionary<ITest, TestResult>();
    public Dictionary<ITest, TestResult> SubTestResults {
        get {
            return subTestResults;
        }
        set {
            subTestResults = value;
        }
    }
}

그 이후의 유일한 까다로운 부분은 어떤 세분화 수준이 어떤 프로젝트를하든 최고의 "벅을위한 뱅"이라고 생각하는 것입니다.

주소록을 작성하려면 엔터프라이즈 검색 엔진보다 테스트가 덜 필요하지만 기본 사항은 실제로 변경되지 않습니다.

행운을 빕니다!


시간이 지남에 따라 세분성 수준이 가장 좋은 것을 알아낼 것입니다. 정기적으로 테스트를 생성하는 다른 사람들의 의견을 들어 보면 현명하게 접근하고 모든 가능한 결과에 대해 로봇 적으로 테스트를 작성하지는 않습니다. 테스트에 대한 나의 첫 소개는 모든 것이 테스트되어야하는 수준의 레벨에있었습니다. 실제로, TDD의 전체 개념은 그 진언을 따르는 것 같습니다.
Ken Pespisa

SubSpec과 같은 프레임 워크 (BDD에서 영감을 얻음)를 사용하면 컨텍스트 설정을 공유하면서 Assert ( "SubTest") 격리를 얻을 수 있다고 생각합니다.
Johannes Rudolph
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.