it-swarm-ko.tech

단위 테스트는 그만한 가치가 있습니까?

나는 작업하는 팀의 개발 프로세스에 단위 테스트를 통합하기 위해 노력하고 있으며 일부 회의론자들이 있습니다. 회의론자 개발자에게 단위 테스트의 가치에 대해 확신시키는 좋은 방법은 무엇입니까? 필자의 경우에는 기능 테스트 나 버그 수정을 추가 할 때 Unit Tests를 추가 할 것입니다. 불행하게도 우리의 코드 기반은 쉽게 테스트 할 수는 없습니다.

573
Ross Fuhrman

우리 사무실에는 매일 다음과 같은 교환 프로그램이 있습니다 :

"이봐, 나는 단지 단위 테스트를 좋아한다. 나는 그저 무언가가 작동하는 방식에 많은 변화를 줄 수 있었고, 그 후에 다시 테스트를 실행하여 아무 것도 깨지지 않았 음을 확인할 수 있었다 ..."

세부 사항은 매일 바뀌지 만 정서는 변하지 않습니다. 단위 테스트와 TDD (Test-Driven Development)는 너무 많은 숨겨진 개인적 이점뿐만 아니라 스스로 수행 할 때까지는 누군가에게 실제로 설명 할 수없는 명백한 이점을 가지고 있습니다.

그러나, 그것을 무시하고, 여기 나의 시도가있다!

  1. 단위 테스트를 사용하면 코드를 빠르게 변경할 수 있습니다. 테스트를 실행했기 때문에 이제는 작동한다는 것을 알 수 있습니다. 필요한 변경을 수행하면 테스트가 다시 작동해야합니다. 이렇게하면 시간을 절약 할 수 있습니다.

  2. TDD는 코딩을 중단해야 할 때를 깨닫도록 도와줍니다. 테스트를 통해 지금까지 충분히 해왔고 조정을 중단하고 다음 문제로 넘어갈 수 있다는 자신감을 얻을 수 있습니다.

  3. 테스트와 코드가 함께 작동하여 더 나은 코드를 얻습니다. 코드가 좋지 않거나 버그가있을 수 있습니다. 테스트가 좋지 않거나 버그가있을 수 있습니다. TDD에서 당신은 둘 다 나쁜/버기가 낮을 확률이 높습니다. 종종 고칠 필요가있는 테스트이지만 여전히 좋은 결과입니다.

  4. TDD는 변비를 코딩하는 데 도움이됩니다. 테스트를 작성하기 전에 크고 기발한 작업에 직면하면 빠르게 움직일 수 있습니다.

  5. Unit Tests는 작업중인 코드의 디자인을 실제로 이해하는 데 도움이됩니다. 코드를 작성하는 대신, 코드를 적용하는 모든 조건과 그로부터 기대할 수있는 출력을 요약하여 시작합니다.

  6. 단위 테스트를 통해 즉각적인 시각적 피드백을 얻을 수 있습니다. 그것은 매우 만족 스럽습니다. 방해가 된 후 중단 한 곳을 선택하는 것이 훨씬 쉽습니다. 그 이유는 어디에 있어야하는지 알 수 있기 때문입니다.

  7. 일반적인 믿음 단위 테스트와 달리 코드를 두 배나 쓰거나 느리게 코딩하는 것을 의미하지는 않습니다. 일단 테스트가 없으면 코딩하지 않고 코딩하는 것보다 빠르고 강력합니다. 테스트 코드 자체는 일반적으로 비교적 사소하며 수행중인 작업에 큰 오버 헤드를 추가하지 않습니다. 이것은 당신이 그것을 할 때 오직 믿을 수있는 것입니다 :)

  8. Fowler는 "불완전한 테스트는 자주 실행되며 절대 작성하지 않은 완벽한 테스트보다 훨씬 뛰어납니다"라고 말한 바 있습니다. 나는 이것이 나의 코드 커버리지의 나머지가 비참하게 완전하지 않더라도 그들이 가장 유용하다고 생각하는 곳에 테스트를 쓸 수있는 권한을주는 것으로 해석한다.

  9. 좋은 단위 테스트는 문서화가 도움이 될 수 있으며 무엇을해야하는지 정의 할 수 있습니다.

  10. 단위 테스트는 코드 재사용에 도움이됩니다. 테스트 와 테스트 를 모두 새 프로젝트로 마이그레이션하십시오. 테스트가 다시 실행될 때까지 코드를 조정하십시오.

내가 참여하고있는 많은 작업은 단위 테스트 (웹 애플리케이션 사용자 상호 작용 등)가 아니지만이 상점에 모든 테스트가 포함되어 있으며 테스트가 끝나면 가장 행복합니다. 접근법을 충분히 높일 수는 없습니다.

722
reefnet_alex

단위 테스트는 체육관에가는 것과 아주 흡사합니다. 당신에게 도움이된다는 것을 알았습니다. 모든 논점이 타당합니다. 그래서 운동을 시작하십시오. 초기 Rush가 있습니다. 그러나 그것은 며칠이 지나면 문제가 될만한 가치가 있는지 궁금해하기 시작합니다. 옷을 갈아 입히고 햄스터 휠로 달리는 데 하루 시간이 걸리며 다리와 팔이 아프다는 것을 확신하지 못합니다.

그런 다음, 아마도 1 ~ 2 주 후에 통증이 사라 지듯이 Big Deadline이 접근하기 시작합니다. 깨어있는 모든 시간을 "유용한"일을하려고 할 때마다 소비해야하므로 체육관에가는 것과 같은 외적인 것들을 잘라냅니다. 너는 습관에서 벗어나, Big Deadline이 끝날 때까지, 너는 정사각형으로 돌아 간다. 당신이 그것을 체육관으로 되돌아 가게하는 것을 관리한다면, 처음으로 당신이 갔던 것처럼 아플 것입니다.

당신이 뭔가 잘못하고 있는지보기 위해서 당신은 독서를해야합니다. 운동의 장점을 찬양하는 모든 사람들, 행복한 사람들에 대해 비합리적인 단점을 느끼기 시작합니다. 당신은 당신이 공통점이 많지 않다는 것을 깨닫습니다. 체육관에 가기 위해 15 분을 운전하지 않아도됩니다. 그들의 건물에 하나가 있습니다. 그들은 운동의 이점에 대해 누구와도 논쟁 할 필요가 없습니다. 그것은 단지 모두가하고 중요한 것으로 받아들이는 것입니다. Big Deadline에 접근하면 상사가 식사를 중단하라고 요구하는 것 이상의 운동이 불필요하다는 말을 듣지 못합니다.

그래서, 당신의 질문에 답하기 위해서 Unit Testing은 보통 노력할 가치가 있지만 필요한 노력의 양은 모든 사람들에게 동일하지 않을 것입니다. 단위 테스트는 코드 품질을실제로가치가없는 회사에서 스파게티 코드 기반을 다루는 경우 엄청난 노력이 필요할 수 있습니다. (많은 관리자들이 Unit Testing의 칭찬을 부릅니다. 그렇다고해서 문제가 될 때마다이를 고수하지는 않습니다.)

프로젝트에 단위 테스트를 도입하려하고 예상했던 모든 햇빛과 무지개를 보지 못한다면 자신을 원망하지 마십시오. 실제로 단위 테스트를 수행하기 위해 새로운 직업을 찾아야 할 수도 있습니다.

421
benzado

확신 할 수있는 가장 좋은 방법은 버그를 찾고, 단위 테스트를 작성하고, 버그를 수정합니다.

이 특정 버그는 다시 나타나지 않을 것이며 테스트를 통해 증명할 수 있습니다.

너가 이것을 충분히하면, 다른 사람은 빨리 붙잡을 것이다.

136
Ed Guiness

나는 단위 테스트를 여러 번 해보았으며, 나는 아직도 내 상황에서 주어진 노력이 가치가 있음을 확신하고있다.

나는 로직의 대부분이 데이터베이스에서 데이터를 생성, 검색 또는 업데이트하는 웹 사이트를 개발한다. 단위 테스트 목적으로 데이터베이스를 "모의"하려고 시도했을 때 매우 지저분 해 보였고 조금 무의미한 것처럼 보였습니다.

비즈니스 논리를 중심으로 단위 테스트를 작성 했더니 장기적으로는 절대로 도움이되지 못했습니다. 프로젝트만으로 대부분 작업하기 때문에 코드의 어떤 영역이 내가 작업중인 것에 의해 영향을 받을지 직관적으로 알기 쉽고이 영역을 수동으로 테스트합니다. 가능한 한 빨리 고객에게 솔루션을 제공하고 싶습니다. 단원 테스트는 시간 낭비입니다. 수동 테스트 목록을 작성하고 직접 테스트 해 보았습니다.

개발자 팀이 프로젝트 작업을하고 서로의 코드를 업데이트 할 때 유용 할 수 있지만, 개발자가 높은 품질의 의사 소통이 가능하고 잘 작성된 코드만으로도 충분하다고 생각합니다. .

38
Ronnie

단위 테스트에 대한 한 가지 좋은 점은 코드가 어떻게 동작 하는지를 문서화하는 것입니다. 좋은 테스트는 일종의 레퍼런스 구현과 같으며 팀원은 코드를보고 자신의 코드를 통합하는 방법을 볼 수 있습니다.

31
pkaeding

단위 테스트는 초기 투자 가치가 있습니다. 몇 년 전 단위 테스트를 시작한 이래로 몇 가지 실질적인 이점을 발견했습니다.

  • 회귀 테스트 는 코드를 변경하는 것에 대한 두려움을 제거합니다 (코드 작업을 보는 따뜻한 빛과 같은 것은 없습니다).
  • 다른 팀 구성원 (그리고 6 개월 만에 자신을위한 ..) 실행 코드 예제
  • 무자비한 리팩토링 - 이것은 매우 보람있는 시도입니다!

코드 스 니펫은 테스트 생성의 오버 헤드를 줄이는 데 큰 도움이 될 수 있습니다. 초 단위로 클래스 외곽선 및 관련 단위 테스트 픽스처를 만들 수있는 스 니펫을 만드는 것은 어렵지 않습니다.

26
Jonathan Webb

가능한 한 적은 테스트를해야합니다!

의미를 밝히기 위해서는 단위 테스트를 충분히 작성해야합니다. 이것은 종종 지나치다. 단위 테스트 비용이 들지 요. 변경하고 테스트를 변경해야하는 경우 민첩성이 떨어집니다. 단위 테스트를 짧고 단정하게 유지하십시오. 그렇다면 그들은 많은 가치가 있습니다.

너무 자주 끊어지지 않을 많은 테스트를보고 크고 서투르며 많은 가치를 제공하지 않습니다. 결국 속도가 느려지 게됩니다.

25
Keith Nicholas

나는 다른 답변에서 이것을 보지 못했지만, 내가 알아 차 렸던 한 가지는 너무 빨리 디버깅 할 수 있었다 . 부울 오류가 발생하여이를 모두 다시 수행해야하는 경우에만 올바른 단계로 코드를 수정하여 앱을 살펴볼 필요가 없습니다. 단위 테스트를 사용하면 디버깅중인 코드로 바로 이동할 수 있습니다.

23
John MacIntyre

[나는 위에서 볼 수없는 것을 만들 수있는 포인트가있다]

"모든 유닛 테스트, 그들은 반드시 그것을 깨닫지 못합니다 - 사실"

그것에 대해 생각해 보면, 아마도 문자열을 구문 분석하고 줄 바꿈 문자를 제거하는 함수를 작성합니다. 초보자 개발자는 명령 줄에서 Main ()으로 구현하거나 단추로 시각적 프런트 엔드를 함께 사용하여 몇 가지 사례를 실행하거나 함수를 몇 개의 텍스트 상자와 단추에 연결 한 다음 무슨 일이야.

그것은 단위 테스트입니다 - 기본 및 잘못 조립하지만 코드의 일부를 테스트합니다.

당신은 좀 더 복잡한 것을 씁니다. 그것은 당신이 (단위 테스트)를 통해 몇 가지 경우 던져 오류를 throw하고 코드로 디버깅 및 추적. 당신은 통과 할 때 가치를보고 그들이 옳은지 또는 틀린지를 결정합니다. 이것은 어느 정도 단위 테스트입니다.

여기에있는 단위 테스트는 실제 동작을 취하고이를 구조화 된 패턴으로 형식화하고 저장하므로 쉽게 테스트를 다시 실행할 수 있습니다. 수동으로 테스트하는 것이 아니라 "적절한"단위 테스트 케이스를 작성하면 경험 한만큼의 시간이 걸리거나 반복적으로 반복 할 수 있습니다

21
Chris Gill

수년 동안 사람들에게 코드에 대한 단위 테스트를 작성해야한다고 설득하려고 노력했습니다. TDD에서와 같이 테스트를 처음 작성 했든 기능을 코딩했는지에 관계없이 항상 코드에 대한 단위 테스트를 수행하는 모든 이점을 설명하려고했습니다. 아무도 나와 의견이 맞지 않습니다. 명백한 것에 대해서는 동의 할 수 없으며 똑똑한 사람이라면 단위 테스트와 TDD의 이점을 볼 수 있습니다.

단위 테스트의 문제는 행동 변화가 필요하다는 것이며 사람들의 행동을 바꾸는 것은 매우 어렵습니다. 말로는 많은 사람들이 동의 할 것이지만, 일을하는 방식에는 많은 변화가 나타나지 않을 것입니다.

당신은 사람들을 설득하여 설득해야합니다. 귀하의 개인적인 성공은 당신이 가질 수있는 모든 주장보다 많은 사람들을 괴롭 히게됩니다. 그들이 당신이 단원 테스트 또는 TDD에 대해 이야기하는 것이 아니라, 당신이 설교하는 것을하고 있고, 성공하면, 사람들은 당신을 모방하려고 노력할 것입니다.

처음에는 단위 테스트를 제대로 작성하지 않으므로 주도적 역할을해야합니다. 따라서이를 수행하는 방법을 설명하고, 방법을 제시하고, 사용 가능한 도구를 코칭해야 할 수 있습니다. 처음 테스트를 작성하고 스스로 작성한 테스트를 검토하고 자신의 경험을 통해 배운 트릭, 숙어 및 패턴을 보여줍니다. 잠시 후, 그들은 스스로 혜택을보기 시작할 것이며 단위 테스트 또는 TDD를 도구 상자에 통합하기 위해 행동을 바꿀 것입니다.

밤에는 변화가 일어나지 않지만 인내심을 가지고 목표를 달성 할 수 있습니다.

16
Curro

테스트 주도 개발의 주요 부분은 테스트 가능한 코드 작성입니다. 처음에는 일종의 타협처럼 보이지만 테스트 할 수있는 코드가 궁극적으로 모듈화되고 유지 보수가 용이하며 판독 가능하다는 것을 알게됩니다. 설득력있는 사람들 에게 도움이 여전히 필요하다면 이것은 단위 테스트의 장점에 관한 간단한 간단한 프레젠테이션입니다.

12
Tom Martin

기존 코드 기반이 단위 테스트에 적합하지 않고 이미 프로덕션 환경에있는 경우 모든 코드를 리팩터링하여 단위 테스트 할 수 있도록 문제를 해결할 수 있습니다.

대신 통합 테스트를 개선하기위한 노력을하지 않는 것이 좋습니다. 단위 테스트없이 작성하는 것이 더 간단하고 QA가 요구 사항 문서에 대한 기능을 검증 할 수 있다면 많은 코드가 있습니다. 그것을 조종해라.

이에 대한 고전적인 예는 GridView에 링크 된 ASPX 페이지에 포함 된 SqlDataReader입니다. 코드는 모두 ASPX 파일에 있습니다. SQL은 저장 프로 시저에 있습니다. 당신은 무엇을 단위 테스트합니까? 페이지가해야 할 작업을 수행하는 경우 실제로 여러 레이어로 다시 디자인해야 자동화 할 항목이 생깁니 까?

11
Eric Z Beard

단위 테스트에 관한 가장 좋은 점 중 하나는 코드를 테스트 할 때 코드를 더 쉽게 테스트 할 수 있다는 것입니다. 테스트를 거치지 않고 생성 된 기존 코드는 단위 테스트를 거치지 않았기 때문에 클래스 사이에 높은 수준의 연결을 제공하는 것은 물론 클래스 내부의 구성하기 어려운 개체 (예 : 전자 메일)를 사용하는 것이 거의 불가능하기 때문에 항상 도전 과제입니다. 보내는 서비스 참조 - 등등. 그러나 이것이 당신을 끌어 내리지 못하게하십시오! 단위 테스트 작성을 시작할 때 전반적인 코드 디자인이 향상 될 것이며, 테스트를 많이할수록 응용 프로그램을 중단하거나 버그를 제기 할 염려없이 더욱 많은 변경 작업을 수행하게 될 것입니다. .

코드를 단위 테스트하는 데는 여러 가지 이유가 있지만 시간이 지남에 따라 테스트를 저장할 시간이 가장 좋은 이유 중 하나라는 것을 알 수 있습니다. 방금 전달한 시스템에서 필자는 수동으로 시스템을 테스트하는 것보다 테스트하는 데 더 많은 시간을 할애해야한다는 주장에도 불구하고 자동화 된 단위 테스트를 주장했습니다. 모든 유닛 테스트가 끝나면, 10 분 안에 400 개가 넘는 테스트 케이스를 실행하고, 코드를 조금 변경해야 할 때마다 코드가 버그없이 작동하는지 확인하는 데 모든 것이 필요했습니다. 의사록. 손으로 400 개 이상의 테스트 케이스를 실행하는 데 드는 시간을 상상할 수 있습니까?

단위 테스트 또는 수락 테스트와 같은 자동화 된 테스트의 경우 모든 사람이 수동으로 수행 할 수있는 작업을 코딩하는 데 낭비되는 노력이라고 생각하며 때로는 사실입니다. 테스트를 한 번만 실행하려는 경우. 자동 테스트의 가장 중요한 부분은 노력없이 여러 번 실행할 수 있고, 두 번째 또는 세 번째 실행 후에는 낭비되는 시간과 노력 이 이미 지불되었음을 의미합니다.

조언의 마지막 부분은 코드를 단위 테스트하는 것뿐만 아니라 테스트를 먼저 수행하는 것입니다 ( TDDBDD 참조). 더)

10
Alexandre Brasil

단위 테스트는 코드를 리팩토링하거나 다시 작성하는 데 특히 유용합니다. 당신이 좋은 단위 테스트 커버 리지를 가지고 있다면, 당신은 자신감을 갖고 리펙터를 할 수 있습니다. 단위 테스트가 없으면 아무 것도 깨뜨리지 않았 음을 보장하기가 어렵습니다.

8
killdash10

나는 문서화가 잘 안되며 큰 코드 기반의 유지 보수 엔지니어로 일하고 있습니다. 코드를 작성한 사람들이 단위 테스트를 작성했으면합니다.
제품 코드를 변경하고 업데이트 할 때마다 몇 가지 조건을 고려하지 않았기 때문에 버그가 생길 수 있습니다.
그들이 코드베이스를 변경하는 것이 쉽고 빠를 것입니다. (동시에 코드베이스가 더 좋은 상태가 될 것입니다.).

단위 테스트는 API 또는 여러 해 동안 지속되어야하고 원래 코더 이외의 사람들이 사용/수정/발전시켜야하는 프레임 워크를 작성할 때 매우 유용하다고 생각합니다.

7
mic.sca

간단히 말해서 네. 그들은 1 온스의 노력으로 가치가 있습니다. 테스트는 하루가 끝날 때까지 여전히 코드이며 일반적인 코드 증가와 마찬가지로 유지 및 유지가 가능하도록 테스트가 결국 리팩토링되어야합니다. GOTCHAS 톤이 있습니다! 유닛 테스트와 관련해서는 오, 사람이 아니야, 아무것도 아냐. 개발자가 여러 가지 단위 테스트보다 더 자신있게 변화를 줄 수 있다는 것을 의미한다.

저는 현재 프로젝트에서 일하고 있습니다 .... 다소 TDD가 있습니다. 우리는 비즈니스 규칙의 대다수를 테스트로 캡슐화했습니다 ... 우리는 현재 약 500 가지 단위 테스트를 실시하고 있습니다. 이 과거의 반복 작업을 통해 데이터 소스를 개편하고 데스크탑 애플리케이션이 데이터 소스와 어떻게 상호 작용 하는지를 살펴 보았습니다. 며칠 만에, 내가 부러진 것을보기 위해 단위 테스트를 계속하고있는 내내 그 시간을 보냈습니다. 변화를 가져라. 테스트를 작성하고 실행하십시오. 네가 부러낸 것을 고쳐라. 세척, 헹굼, 필요하면 반복하십시오. 전통적으로 QA와 배가 많은 스트레스를 겪었던 것은 짧고 즐거운 경험이었습니다.

앞면 준비, 약간의 추가 노력, 그리고 핵심 기능/기능으로 주변을 더럽힐 필요가있을 때 나중에 10 배를 지불합니다.

나는이 책을 샀다 - 그것은 xUnit Testing 지식의 성경이다 - 아마도 선반에서 가장 많이 언급 된 책 중 하나 일 것이다. 나는 매일 그것을 참조한다 : link text

7
cranley

가끔 나 자신이나 동료 중 한 명은 약간의 버그를 발견하기 위해 몇 시간을 보내고, 버그의 원인은 코드가 단위 테스트를 거치지 않은 시간의 90 %에 해당됩니다. 개발자가 시간을 절약하기 위해 모서리를 자르고 있기 때문에 단위 테스트가 존재하지 않지만, 더 이상 디버깅을하지는 않습니다.

단위 테스트를 작성하는 데 소량의 시간을 사용하면 향후 디버깅 시간을 절약 할 수 있습니다.

7
Jon Cahill

당신이 말했을 때, "우리의 코드 기반은 쉬운 테스트에 적합하지 않습니다"는 코드 냄새의 첫 징후입니다. 단위 테스트 작성은 일반적으로 코드를 더 많이 테스트 할 수 있도록 코드를 다르게 작성한다는 의미입니다. 필자가 수년 동안 테스트를 작성해야하는 코드를 작성하면서 보았던 것, 이것이 더 나은 디자인을 내놓을 것을 강요 한 것처럼 내 의견으로는 좋은 일이다.

6
Keith Elder

나도 몰라. 많은 곳에서 단위 테스트를하지는 않지만 코드의 품질은 좋습니다. 마이크로 소프트는 단위 테스트를하지만, 빌 게이츠는 프레젠테이션에서 파란 화면을 보냈다.

6
BigTiger

단위 테스트는 분명 노력의 가치가 있습니다. 불행하게도 구현하기 어려운 (그러나 불행히도 공통적 인) 시나리오를 선택했습니다.

단위 테스트를 할 때 얻을 수있는 가장 좋은 점은 처음부터 몇 가지, 선택하고 작은 프로젝트에서 사용하는 것입니다. 클래스를 구현하기 전에 단위 테스트를 작성할만큼 충분히 운이 좋았습니다 (이 인터페이스는 이미 포인트). 적절한 단위 테스트를 통해 학생들이 아직 초기 단계에있는 동안 버그가 발견 될 것이고 미래에 의심의 여지없이 통합 될 복잡한 시스템 근처에서 버그를 발견하고 수정할 것입니다.

소프트웨어가 객체 지향적 인 경우, 너무 많은 노력을 기울이지 않고도 클래스 수준에서 단위 테스트를 추가 할 수 있어야합니다. 운이 좋지 않은 사람이라면 가능한 한 어디에서나 단위 테스트를 통합해야합니다. 새로운 기능을 추가 할 때 새로운 부분이 명확한 인터페이스로 잘 정의되어 있는지 확인하십시오. 단원 테스트를 통해 인생을 훨씬 쉽게 할 수 있습니다.

6
Matt

주제에 관한 매우 큰 블로그 글을 썼습니다. 단위 테스트만으로는 가치가없는 것으로 나타 났으며 마감일이 가까워지면 대개 잘랐습니다.

"테스트 후"검증 관점에서 단원 테스트에 대해 이야기하는 대신 구현 전에 spec/test/아이디어를 작성하기 위해 출발했을 때 발견 된 진정한 가치를 살펴 봐야합니다.

이 간단한 아이디어는 내가 소프트웨어를 작성하는 방식을 바꾸었고 나는 "옛"방식으로 돌아 가지 않을 것입니다.

테스트 첫 발달이 어떻게 나의 삶을 변화 시켰는가

5
Toran Billups

아무도 언급하지 않은 한 가지 점은 모든 개발자가 실제로 기존 자동화 테스트를 실행하고 업데이트하겠다는 약속을 얻는 것입니다. 새로운 개발로 인해 다시 돌아 왔고 발견 된 자동화 된 테스트는 많은 가치를 잃어 버리고 자동 테스트가 실제로 고통스럽게 만듭니다. 대부분의 테스트에서는 개발자가 코드를 수동으로 테스트했기 때문에 버그를 나타내지 않으므로 버그를 업데이트하는 데 걸리는 시간은 낭비입니다.

회의론자들이 단위 테스트에서 수행하는 작업을 파괴하지 않도록 설득하는 것이 테스트에서 가치를 얻는 데 훨씬 더 중요하며 더 쉬울 수도 있습니다.

저장소에서 업데이트 할 때마다 새로운 기능으로 인해 손상된 테스트를 업데이트하는 데는 생산성이없고 재미도 없습니다.

3
Samuel Åslund

나는 TDD를 몇 년 전에 발견했고, 이후로 그것을 사용하여 모든 애완 동물 프로젝트를 작성했습니다. 프로젝트를 TDD로 전환하는 데 거의 같은 시간이 걸릴 것으로 예상했지만 최종 제품에 대한 확신이 높아져서 성취감을 느끼지 못합니다.

나는 또한 내가 디자인 스타일을 향상 시킨다는 것을 느낀다. (내가 모의 작업을해야 할 경우를 대비해 훨씬 더 인터페이스 지향적이다.) 그리고 상단에 녹색 포스트가 쓰면 "변비를 코딩"하는 데 도움이된다. 다음 글을 쓰거나, 당신 앞에서 힘든 일이 있다면, 작게 글을 쓸 수 있습니다.

마지막으로, TDD의 가장 유용한 응용 프로그램이 디버깅에 있습니다. 이는 이미 반복적 인 방식으로 버그를 생성하도록 프로젝트를 자극 할 수있는 심문 프레임 워크를 이미 개발했기 때문입니다.

3
Kaz Dragon

예 - 단위 테스트는 분명 노력할만한 가치가 있지만 은화가 아님을 알아야합니다. 단위 테스트는 작동하므로 코드 변경에 따라 테스트를 업데이트하고 관련성을 유지해야하지만 제안 된 가치는 사용자가 투입해야하는 가치가 있습니다. 리팩토링 기능을 사용하면 기능을 항상 검증 할 수 있으므로 엄청난 이점이 있습니다 변경 코드 다음에 테스트를 실행하십시오. 그 트릭은 테스트중인 작업 단위 나 작업 단위 테스트의 요구 사항에 정확히 매달려서는 안되며, 단위 테스트가 실제로 기능 테스트 일 때 등입니다. 사람들은 몇 시간 동안이 내용에 대해 논할 것입니다. 결국 코드 작성으로 수행하는 모든 테스트가 수행하지 않는 것보다 낫습니다. 다른 공리는 품질에 관한 것이지 수량에 관한 것이 아닙니다. 나머지 1000 개는 실제로 유용하지 않거나 특정 도메인의 비즈니스 규칙 등과 같은 특정 도메인을 테스트하지 않기 때문에 본질적으로 의미가없는 1000 개의 테스트 코드 기반을 보았습니다. 또한 30 %의 코드 커버리지를 가진 코드베이스를 보았지만이 테스트는 관련 코드, 코드 작성 방법을 표현할 때 의미 있고 실용적이었습니다.

새로운 프레임 워크 또는 코드베이스를 탐색 할 때 가장 좋아하는 트릭 중 하나는 'it'에 대한 단위 테스트를 작성하여 작업 방법을 발견하는 것입니다. 마른 문서를 읽는 대신 새로운 것을 배울 수있는 좋은 방법입니다 :)

3
Vinny Carpenter

나는 최근에 직장에서 똑같은 경험을했고 그 중 대부분이 이론적 인 이점을 알고 있었지만 구체적으로 그 혜택을 팔아야한다는 것을 알았 기 때문에 내가 사용했던 점이 여기에있다.

  • 네거티브 테스팅을 수행 할 때, 예기치 않은 입력 (null 포인터, 범위를 벗어나는 값 등)을 처리하는 경우 시간을 절약 할 수 있습니다. 이러한 모든 작업을 단일 프로세스에서 수행 할 수 있기 때문입니다.
  • 이들은 컴파일 타임에 변경 표준에 관한 즉각적인 피드백을 제공합니다.
  • 정상적인 런타임 중에 노출되지 않을 수있는 내부 데이터 표현을 테스트하는 데 유용합니다.

그리고 큰 것 ...

  • 단위 테스트가 필요하지 않을 수도 있지만 누군가 다른 사람이 들어 와서 코드를 완전히 이해하지 않고 수정하면 바보 같은 실수를 많이 범할 수 있습니다.
3
dlanod

내 경험에 비추어 볼 때, 단위 테스트와 통합 테스트는 복잡한 소프트웨어 환경에서 반드시 있어야합니다.

팀의 개발자가 단위 테스트를 작성하도록 유도하려면 개발 환경 (예 : 일일 빌드 프로세스)에서 단위 테스트 회귀 분석을 통합하는 것이 좋습니다.

일단 단위 테스트가 실패하면 문제를 찾기 위해 디버깅하는 데 너무 많은 시간을 할애 할 필요가 없다는 것을 개발자가 알게되면 문제를 발견하는 것이 더 좋습니다.

다음은 그러한 기능을 제공하는 도구입니다.

단위 테스트 회귀 분석 도구

2
Liorp

NUnit을 사용하고 있다면 간단하지만 효과적인 데모는 앞에 NUnit의 자체 테스트 스위트를 실행하는 것입니다. 코드베이스에 운동을주는 실제 테스트 스위트를 보는 것은 천 단어의 가치가 있습니다 ...

2
Garth Gilmour

단위 테스트에 대해 염두에 두어야 할 점 중 하나는 개발자에게 안락함이라는 것입니다.

대조적으로 기능 테스트는 사용자를위한 것입니다. 기능 테스트를 추가 할 때마다 사용자가 볼 수있는 것을 테스트하는 것입니다. 단원 테스트를 추가하면 개발자로서의 삶이 편하게됩니다. 그 점에서 사치에 불과합니다.

단위 또는 기능 테스트를 작성할 때 선택해야 할 때이 이분법을 염두에 두십시오.

2
Cedric Beust

나는 대다수의 견해와 반대되는 견해에 동의한다. 단위 테스트를 쓰지 말라. 특히 프로토 타입 무거운 프로그래밍 (예를 들면 AI) 단위 테스트와 결합하기가 어렵습니다.

2
DSblizzard

단위 테스팅은 개발자가 소유하고있는 것보다 더 큰 프로젝트에서 많은 도움이됩니다. 그들은 당신이 체크 인 전에 유닛 테스트 슈트를 실행하고 당신이 무언가를 파산했는지 발견 할 수있게 해줍니다. 이렇게하면 다른 사람이 체크인 한 버그를 기다리는 동안 엄지 손가락을 움직여 엄지 손가락을 움직여야하거나, 변경 사항을 되돌릴 수있는 번거 로움을 겪을 때 로트 가 삭감됩니다 당신은 어떤 일을 끝낼 수 있습니다. 또한 리팩토링에서 매우 중요하므로 리팩터링 된 코드가 원래 코드에서 수행 한 모든 테스트를 통과 할 수 있습니다.

2
Max Rible Kaehn

단위 테스트 스위트를 사용하면 나머지 기능을 그대로두고 코드를 변경할 수 있습니다. 그것의 큰 장점. 새로운 기능을 코딩 할 때 Unit test sutie 및 regression test suite를 사용하십니까?.

2
Shinwari

단위 테스트의 전체적인 요점은 테스트를 쉽게하는 것입니다. 자동입니다. "시험을 치르십시오."그리고 당신은 끝났습니다. 직면 한 문제 중 하나가 코드를 테스트하기가 어렵다면 그것이 단위 테스트를 사용하는 가장 좋은 이유입니다.

1
Deathbob

지금은 단위 테스트가 이전에 작성된 클래스를 변경해야했습니다.
테스트 자체는 잘 작성되었으며 내가 생각조차하지 못했던 테스트 시나리오가 포함되었습니다.
다행스럽게도 모든 테스트가 통과되었고, 필자의 변화가 신속하게 검증되어 확신있게 테스트 환경에 투입되었습니다.

1
crowne

수동으로 소프트웨어를 테스트 할 때는 일반적으로 사용하는 작은 테스트/동작 세트가 있습니다. 궁극적으로 입력 데이터 또는 동작을 자동으로 변형시켜 알려진 문제를 해결할 수 있습니다. 일이 올바르게 작동하지 않는다는 것을 상기시키기 위해 단위 테스트가 있어야합니다.

필자는 테스트 전에 코드를 작성하고 새로운 테스트/데이터를 추가하여 주 코드의 기능을 향상시키는 것이 좋습니다!

1
Ray Hayes

물리학 학생으로서 나는 실제로 내 코드가 정상적으로 작동한다는 것을 증명 할 것을 매우 강요합니다. 이것은 논리적으로 증명할 수 있습니다. 구현이 복잡 해짐에 따라 어려움이 급격히 증가하거나 좋은 테스트를 통해 기능에 대한 경험적 증거를 최대한 (가능한 한 가깝게) 만들 수 있습니다.

논리적 기능 증명을 제공하지 않으면 테스트해야합니다. 유일한 대안은 "코드가 작동한다고 생각합니다."

1
Fredrik

@ George Stocker "불행히도 우리의 코드베이스는 쉬운 테스트를 제공하지 않습니다." 누구나 단위 테스트에 이점이 있지만이 코드 기반에서는 비용이 많이들 것이라고 생각합니다. 비용이 혜택보다 크다면 왜 열렬히해야합니까? 당신의 동료 들으십시오; 아마도 단위 테스트의인지 된 통증이 단위 테스트의 인식 된 가치보다 큽니다.

특히, 가능한 한 빨리 가치를 얻으려고 노력하고, "xUnit is green"값은 아니지만 사용자와 관리자가 가치있는 깨끗한 코드를 얻으십시오. 어쩌면 당신은 하나의 반복을위한 단위 테스트를 위임 받아야하고 노력의 가치가 있는지 없는지 논의해야 할 것입니다.

1
Trystan Spangler

단위 테스트와 관련이없는 테스트를 먼저하십시오. 나는 주로 Perl에서 작업하기 때문에 Perl에 특정한 예제이지만 적응할 수 있습니다.

  • 모든 모듈이 올바르게로드되고 컴파일됩니까? Perl에서는 다음과 같은 코드베이스에서 Foo.pm에 대한 Foo.t를 작성합니다.

    use_ok( 'Foo' );
    
  • 모든 POD (Plain Ol 'Documentation)이 제대로 포맷 되었습니까? Test :: Pod를 사용하여 모든 파일에서 모든 POD의 형식이 올바른지 확인하십시오.

당신은 이것들이 큰 것들이라고 생각하지 않을 수도 있고, 그렇지 않다고 생각할 수도 있습니다. 그러나 나는 당신이 약간의 기복을 잡을 것이라고 보장 할 수 있습니다. 이 테스트가 한 시간에 한 번 실행되고 누군가의 조기 커밋을 잡으면 사람들에게 "이봐, 그거 꽤 멋지다"고 말할거야.

1
Andy Lester

단위 테스트의 이점 중 하나는 예측 가능성입니다.

단위 테스트를하기 전에 코드를 작성하는 데 걸리는 시간을 엄밀하게 예측할 수 있었지만 디버깅 할 시간이 얼마나되는지 예측할 수 없었습니다.

요즘은 어떤 테스트를 작성할 것인지 계획 할 수 있으므로 코딩이 얼마나 오래 걸릴지 알고 코딩이 끝나면 시스템이 이미 디버깅됩니다. 이것은 개발 프로세스에 예측 가능성을 가져 오는데, 이는 많은 압박감을 제거하지만 여전히 모든 기쁨을 유지합니다!.

1
Raz

단위 테스트는 고품질 코드를위한 가장 많이 채택 된 방법론 중 하나입니다. 보다 안정되고 독립적이며 문서화 된 코드에 대한 기여도는 이미 입증되었습니다. 단위 테스트 코드는 저장소의 중요한 부분으로 간주되어 개발 및 유지 관리가 필요합니다. 그러나 개발자는 종종 단위 테스트에 투자 한 리소스가 예상 한만큼 유익하지 못한 상황에 직면합니다. 이상적인 세계에서 우리가 코딩하는 모든 메소드는 코드를 다루고 코드의 정확성을 검증하는 일련의 테스트를 갖습니다. 그러나 일반적으로 시간 제한으로 인해 일부 테스트를 건너 뛰거나 품질이 떨어지는 테스트를 작성합니다. 그러한 현실에서, 단위 테스트 개발 및 유지 보수에 투자 된 자원의 양을 염두에 두면서 가용 시간을 고려하여 어느 코드가 가장 적합한 테스트를 받아야하는지 스스로에게 질문해야합니다. 기존 테스트에서 어떤 테스트가 실제로 유지 및 관리 할 가치가 있습니까? 참조 여기

0
RoiG

단위 테스트를 통해 전체 개발 비용을 줄이면서 적은 수의 버그로 소프트웨어를 출시 할 수 있습니다. 단위 테스트의 이점 이점에 대한 링크를 클릭하여 링크를 클릭 할 수 있습니다 .

0
Steve_0

누구를 설득하려고합니까? 엔지니어 또는 매니저? 엔지니어 동료들에게 확신시키려는 경우 가장 좋은 방법은 고품질의 소프트웨어를 만들고 싶다는 욕구에 호소하는 것입니다. 버그를 발견 한 수많은 연구가 있으며, 좋은 일을하는 데 신경 쓰면 충분합니다.

경영진을 설득하려는 경우, 발견되지 않을 결함의 비용이 테스트 작성 비용보다 많다는 것을 말하는 일종의 비용/혜택 추론을해야 할 가능성이 큽니다. 고객 신뢰도 저하와 같은 비경제적인 비용도 포함해야합니다.

0
Craig H

이것은 매우 .Net 중심이지만, 아무도 Pex?

나는 그것을 시도 할 때까지 매우 회의적이었다. 내가 생각하기 전에 "실제로 doing 나에게 이익이된다는 것을 이해할 때까지이 개념에 확신을 가지지 않을 것이다". 내 마음을 바꾸고 "나는 care 이렇게 치명적인 예외의 위험이 있다는 것을 어떻게 알 수 있는지, 그러나 is 이제 처리해야합니다 "

아마도이 동작의 유일한 단점은 everything 플래그를 지정하고 6 개월 백 로그를 제공한다는 것입니다. 그러나 코드 빚이 있었다면 항상 코드 빚이 있었지만 몰랐습니다. PM에게 수십 점의 실패가있을 것으로 예상 할 때 2 십만 점의 실패 가능성이 있다고 말하면, 그 개념은 를 먼저 설명하는 것이 중요합니다) .

0
Tom W