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

작업중인 팀의 개발 프로세스에 단위 테스트를 통합하려고 노력하고 있으며 일부 회의론자가 있습니다. 회의 론적 개발자에게 단위 테스트의 가치를 확신시키는 좋은 방법은 무엇입니까? 필자의 경우에는 기능 또는 버그 수정을 추가 할 때 단위 테스트를 추가 할 것입니다. 불행히도 우리의 코드베이스는 쉬운 테스트에 적합하지 않습니다.

우리 사무실에는 매일 다음과 같은 교환이 있습니다.

"남자, 나는 단지 단위 테스트를 좋아한다. 나는 무언가가 작동하는 방식에 많은 변화를 줄 수 있었고, 다시 테스트를 통해 아무것도 부수 지 않았다는 것을 확인할 수 있었다 ..."

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

그러나 그것을 무시하고 여기 내 시도가 있습니다!

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

2. TDD를 사용하면 코딩을 중지 할시기를 알 수 있습니다. 당신의 테스트는 당신이 지금까지 충분히 해왔음을 확신하고 조정을 멈추고 다음 단계로 넘어갈 수 있습니다.

3. 테스트와 코드는 더 나은 코드를 달성하기 위해 함께 작동합니다. 코드가 잘못되었거나 버그가있을 수 있습니다. 테스트가 나쁘거나 버그가있을 수 있습니다. TDD에서는의 기회에 은행되어 모두 있는 나쁜 / 버그 존재가 부족할 수 있습니다. 종종 수정이 필요한 테스트이지만 여전히 좋은 결과입니다.

4. TDD는 코딩 변비에 도움이됩니다. 크고 어려운 작업에 직면했을 때 미리 테스트를 작성하면 빠르게 이동할 수 있습니다.

5. 단위 테스트는 작업중인 코드의 디자인을 실제로 이해하는 데 도움이됩니다. 무언가를하기 위해 코드를 작성하는 대신, 코드의 대상이되는 모든 조건과 그로부터 기대할 수있는 결과를 요약하여 시작합니다.

6. 단위 테스트는 즉각적인 시각적 피드백을 제공하며, 완료되면 모든 녹색 표시등의 느낌을 좋아합니다. 매우 만족 스럽습니다. 또한 고정이 필요한 다음 적색 표시등으로 어디를 가야하는지 알 수 있기 때문에 중단 후 중단 한 위치를 선택하는 것이 훨씬 쉽습니다.

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

8. 나는 파울러가 말했다 : "완전히 실행되는 불완전한 테스트는 전혀 작성되지 않은 완벽한 테스트보다 훨씬 낫다"고 말했다. 나는 이것을 코드 작성의 나머지 부분이 불완전한 경우에도 가장 유용하다고 생각되는 테스트를 작성할 수있는 권한을 부여하는 것으로 해석합니다.

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

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

내가 참여한 많은 작업은 Unit Test가 잘되지 않지만 (웹 응용 프로그램 사용자 상호 작용 등) 우리는 모두이 상점에서 감염된 테스트이며 테스트를 묶었을 때 가장 행복합니다. 나는 그 접근법을 충분히 추천 할 수 없다.

단위 테스트는 체육관에가는 것과 비슷합니다. 당신은 그것이 당신에게 좋다는 것을 알고 있습니다. 초기 서두가 있지만, 며칠 후에 문제가 가치가 있는지 궁금해지기 시작합니다. 옷을 갈아 입고 햄스터 바퀴를 타기 위해 하루 중 한 시간을 보내고 있으며 다리와 팔이 아프지 않은 것 외에는 다른 것이 있는지 잘 모르겠습니다.

그런 다음 1 ~ 2 주 후에 통증이 사라지듯이 큰 기한이 다가 오기 시작합니다. "유용한"작업을 수행하기 위해 깨어있는 시간마다 시간을 보내야하므로 체육관에가는 등의 불필요한 물건을 제거해야합니다. 당신은 습관에서 벗어나고, 큰 마감일이 끝날 무렵, 당신은 정사각형으로 돌아 왔습니다. 당신이 체육관으로 다시 돌아갈 수 있다면, 당신이 처음 갔을 때처럼 기분이 나빠집니다.

당신은 뭔가 잘못하고 있는지 확인하기 위해 약간의 독서를한다. 당신은 운동의 미덕을 칭찬하는 모든 적합하고 행복한 사람들을 향한 약간의 비이성적 인 침을 느끼기 시작합니다. 당신은 공통점이 많지 않다는 것을 알고 있습니다. 그들은 체육관에 가기 위해 15 분을 운전할 필요가 없습니다. 그들의 건물에는 하나가 있습니다. 그들은 운동의 이점에 대해 다른 사람과 논쟁 할 필요가 없습니다. 그것은 모두가 중요하게 받아들이고 받아들이는 것입니다. 큰 기한이 다가 오면, 상사가 식사를 중단하라고 요구하는 것 이상으로 운동이 불필요하다는 말은 들리지 않습니다.

따라서 귀하의 질문에 대답하기 위해 단위 테스트는 일반적으로 노력할 가치가 있지만 필요한 노력의 양이 모든 사람에게 동일하지는 않습니다. 실제로 코드 품질을 중요시 하지 않는 회사에서 스파게티 코드 기반을 다루는 경우 단위 테스트에 많은 노력이 필요할 수 있습니다. (많은 관리자들이 Unit Testing의 칭찬을 부를 것이지만 그것이 중요 할 때 그것을 고수한다는 의미는 아닙니다.)

작업에 단위 테스팅을 도입하려고하는데 기대했던 모든 햇빛과 무지개를 보지 못하는 경우 자신을 비난하지 마십시오. 단위 테스트를 실제로 수행하려면 새로운 직업을 찾아야 할 수도 있습니다.

가장 확실한 방법은 ... 버그를 찾고, 단위 테스트를 작성하고, 버그를 수정하십시오.

이 특정 버그는 다시 나타나지 않을 것이므로 테스트를 통해 확인할 수 있습니다.

이 작업을 충분히 수행하면 다른 사람들이 빨리 따라 잡을 것입니다.

thetalkingwalnut가 묻습니다.

회의 론적 개발자에게 단위 테스트의 가치를 확신시키는 좋은 방법은 무엇입니까?

여기의 모든 사람들은 왜 단위 테스트가 좋은지에 대해 많은 이유들을 모아 놓을 것입니다. 그러나 나는 종종 누군가에게 무언가를 설득하는 가장 좋은 방법은 그들의 주장 에 귀 를 기울이고 그것을 단계별로 다루는 것임을 알게 됩니다. 당신이 듣고 그들의 걱정을 말로 표현하도록 돕는다면, 당신은 각각의 문제를 해결하고 그것들을 당신의 관점으로 전환 할 수 있습니다 (또는 최소한 다리를 세우지 않고 두십시오). 누가 알아? 아마도 그들은 왜 단위 테스트가 당신의 상황에 적합하지 않은지를 확신시켜 줄 것입니다. 가능성은 없지만 가능합니다. 아마도 당신이 단위 테스트에 대해 그들의 주장을 게시한다면, 우리는 반론을 식별하는 데 도움을 줄 수 있습니다.

논쟁의 양쪽을 듣고 이해하는 것이 중요합니다. 사람들의 관심사에 관계없이 단위 테스트를 너무 열심히 시도하면 종교적 전쟁이 생길 수 있습니다. 느리게 채택하고 가장 적은 비용으로 가장 큰 혜택을 볼 수있는 곳에 적용하여 시작하면 단위 테스트의 가치를 입증하고 사람들을 설득 할 수있는 더 나은 기회를 가질 수 있습니다. 나는 이것이 쉬운 것처럼 쉽지 않다는 것을 알고있다. 설득력있는 주장을하기 위해서는 보통 시간과 신중한 측정이 필요하다.

단위 테스트는 다른 도구와 마찬가지로 도구이며, 이점 (잡기 버그)이 비용을 능가하는 방식으로 작성해야합니다 (작성 노력). 이해가되지 않는 곳에서는 사용하지 말고 도구, 검사, 어설 션, 코드 분석기, 공식적인 방법 등 도구의 일부일뿐임을 기억하십시오. 내가 개발자에게 말하는 것은 다음과 같습니다.

1. 필요하지 않은 이유 (예 : 너무 단순하거나 가치가 너무 어려운 이유)와 방법이 다른 방법으로 검증되는 방법 (예 : 검사, 주장) 공식적인 방법, 대화식 / 통합 테스트). 검사 및 공식적인 증거와 같은 일부 검증은 특정 시점에서 수행 된 후 생산 코드가 변경 될 때마다 반복해야한다는 점을 고려해야합니다. 반면에 단위 테스트 및 어설 션은 회귀 테스트 (한 번 작성하고 이후에 반복적으로 실행)로 사용할 수 있습니다. ). 때때로 나는 그들에 동의하지만, 더 자주 메소드가 단위 테스트하기에 너무 간단한 지 또는 너무 어려운지에 대해 토론합니다.

   • 개발자가 방법이 실패하기에 너무 단순 해 보인다고 주장하는 경우 간단한 5 줄 단위 테스트를 작성하는 데 60 초가 걸리지 않습니까? 이 5 줄의 코드는 다음 해 이상 매일 밤마다 실행되며 (오늘 밤에 빌드합니까?) 15 분 이상 걸리는 문제를 발견 한 경우에도 한 번이라도 노력할 가치가 있습니다. 디버그하십시오. 또한 쉬운 단위 테스트를 작성하면 단위 테스트 수가 증가하여 개발자가보기 좋게됩니다.

   • 반면에 개발자가 방법을 단위 테스트하기가 너무 어려워 보인다고 주장하는 경우 (필요한 노력을 기울일 필요는 없음) 아마도 쉬운 부분을 테스트하기 위해 방법을 분할하거나 리팩토링해야한다는 좋은 증거 일 수 있습니다. 일반적으로 이들은 싱글 톤과 같은 비정상적인 리소스, 현재 시간 또는 데이터베이스 결과 집합과 같은 외부 리소스에 의존하는 방법입니다. 이러한 메소드는 일반적으로 자원을 가져 오는 메소드 (예 : getTime () 호출)와 자원을 인수로 취하는 메소드 (예 : 시간 소인을 매개 변수로 사용)로 리팩토링해야합니다. 리소스를 검색하는 메서드 테스트를 건너 뛰고 대신 리소스를 인수로 사용하는 메서드에 대한 단위 테스트를 작성합니다. 일반적으로 이렇게하면 단위 테스트 작성이 훨씬 간단 해 지므로 작성하는 것이 좋습니다.

2. 개발자는 단위 테스트가 얼마나 포괄적이어야하는지 "모래에 선"을 그려야합니다. 나중에 개발 단계에서 버그를 발견 할 때마다보다 포괄적 인 단위 테스트로 문제가 발생했는지 확인해야합니다. 그러한 버그가 반복해서 발생하는 경우 향후 "보다 포괄적 인 단위 테스트 작성 (현재 버그에 대한 단위 테스트 추가 또는 확장 시작)"으로 "라인"을 이동해야합니다. 그들은 올바른 균형을 찾아야합니다.

단위 테스트를 실현하기 위해 중요한 은색 총알없는 거기 이다 너무 많은 단위 테스트와 같은 일이. 직장에서 배운 교훈을 얻을 때마다 "더 많은 단위 테스트를 작성해야합니다"라는 말을 듣게됩니다. 경영진은 "단위 테스트"== "좋음"이라는 헤드에 부딪 혔기 때문에 동의했다.

그러나 "더 많은 단위 테스트"의 영향을 이해해야합니다. 개발자는 일주일에 ~ N 줄의 코드 만 작성할 수 있으며 해당 코드의 몇 퍼센트가 단위 테스트 코드 대 프로덕션 코드 여야하는지 파악해야합니다. lax 직장은 단위 테스트로 10 %의 코드와 생산 코드로 90 %의 코드를 가질 수 있으므로 많은 버그가 있지만 기능이 많은 제품 (MS Word 생각)이 생성됩니다. 반면에 90 % 단위 테스트와 10 % 생산 코드를 갖춘 엄격한 상점은 기능이 거의없는 견고한 제품을 갖게됩니다 ( "vi"라고 생각하십시오). 후자의 제품 충돌에 대한 보고서는 결코 듣지 못할 수도 있지만 코드의 품질과 관련하여 판매되지 않는 제품과 관련이있을 수 있습니다.

더 나쁜 것은, 아마도 소프트웨어 개발에서 확실한 것은 "변화는 불가피하다"는 것입니다. 엄격한 상점 (90 % 단위 테스트 / 10 % 생산 코드)이 정확히 2 개의 기능 (생산 코드의 5 % == 1 기능이라고 가정)을 갖는 제품을 작성한다고 가정하십시오. 고객이 와서 기능 중 하나를 변경하면 코드의 50 % (단위 테스트의 45 % 및 생산 코드의 5 %)가 변경됩니다. lax shop (10 % 단위 테스트 / 90 % 생산 코드)에는 18 개의 기능이있는 제품이 있지만 그 중 어느 것도 잘 작동하지 않습니다. 고객은 4 가지 기능에 대한 요구 사항을 완전히 개선합니다. 변경이 4 배나되었지만 코드베이스의 절반 만 폐기됩니다 (~ 25 % = ~ 4.4 % 단위 테스트 + 생산 코드의 20 %).

내 요점은 단위 테스트 사이의 균형이 너무 적다는 것을 이해해야한다는 것입니다. 본질적으로 문제의 양쪽 측면을 모두 생각했습니다. 동료 및 / 또는 경영진을 설득 할 수 있다면 신뢰를 얻거나 경쟁에서 이길 가능성이 높아집니다.

나는 여러 번 단위 테스트를 해왔으며, 여전히 내 상황에서 노력할만한 가치가 있다고 확신해야합니다.

나는 논리의 많은 부분이 데이터베이스에서 데이터를 생성, 검색 또는 업데이트하는 웹 사이트를 개발합니다. 단위 테스트 목적으로 데이터베이스를 "모의"하려고 시도했을 때 데이터베이스가 매우 지저분하고 약간 무의미 해 보였습니다.

비즈니스 로직에 대한 단위 테스트를 작성했을 때 실제로 도움이되지 않았습니다. 나는 주로 프로젝트 자체에서만 작업하기 때문에 작업중인 코드의 영향을받을 수있는 코드 영역을 직관적으로 알고 경향이 있습니다. 가능한 빨리 고객에게 솔루션을 제공하고 싶습니다. 단위 테스트는 종종 시간 낭비입니다. 수동 테스트 목록을 작성하고 직접 살펴보고 갈 때 똑딱 거립니다.

개발자 팀이 프로젝트를 수행하고 서로의 코드를 업데이트 할 때 도움이 될 수 있음을 알 수 있지만, 개발자의 품질이 우수하고 의사 소통이 잘되어 있고 잘 작성된 코드이면 충분하다고 생각합니다. .

단위 테스트의 장점 중 하나는 코드의 작동 방식에 대한 설명서 역할을한다는 것입니다. 좋은 테스트는 일종의 참조 구현과 비슷하며 팀원은 테스트를 통해 코드를 통합하는 방법을 확인할 수 있습니다.

단위 테스트는 초기 투자 가치가있다. 몇 년 전에 단위 테스트를 사용하기 시작한 이후 몇 가지 실질적인 이점이 있습니다.

• 회귀 테스트 는 코드 변경에 대한 두려움을 제거합니다.
• 다른 팀 구성원 (및 6 개월 후의 사용자를 위한 실행 코드 예제 )
• 무자비한 리팩토링 -이것은 엄청나게 보람입니다, 시도하십시오!

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

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

즉, 의도를 드러내기에 충분한 단위 테스트를 작성해야합니다. 이것은 종종 광택이납니다. 단위 테스트 비용이 발생합니다. 변경하고 테스트를 변경해야하는 경우 민첩성이 떨어집니다. 단위 테스트는 짧고 달콤합니다. 그런 다음 많은 가치가 있습니다.

너무 자주 나는 결코 깨지지 않고, 크고 멍청하며 많은 가치를 제공하지 않는 많은 테스트를 보게됩니다.

나는 다른 답변에서 이것을 보지 못했지만 한 가지 눈에 띄는 것은 너무 빨리 디버깅 할 수 있다는 것 입니다. 코드를 수정하기 위해 올바른 일련의 단계로 앱을 드릴 다운 할 필요가 없으며 부울 오류가 발생하여 다시 수행해야한다는 것을 알 수 있습니다. 단위 테스트를 사용하면 디버깅중인 코드로 바로 이동할 수 있습니다.

[위에서 볼 수 없도록하는 요점이 있습니다]

"모든 단위 테스트, 반드시 그것을 인식 할 필요는 없습니다-사실"

생각해보십시오. 문자열을 구문 분석하고 줄 바꿈 문자를 제거하는 함수를 작성하십시오. 초보자 개발자는 Main ()에서 구현하여 명령 줄에서 몇 가지 사례를 실행하거나 단추로 시각적 프런트 엔드를 뭉개고 함수를 몇 개의 텍스트 상자와 단추에 묶고 참조하십시오. 무슨 일이야.

그것은 단위 테스트입니다-기본적이고 잘못 구성되었지만 몇 가지 경우에 대해 코드 조각을 테스트합니다.

더 복잡한 것을 씁니다. (단위 테스트)를 통해 몇 가지 사례를 던지고 코드로 디버그하고 추적하면 오류가 발생합니다. 당신이 통과 그들이 옳고 그름 경우 결정과 같이 값을 확인합니다. 이것은 어느 정도 단위 테스트입니다.

여기서 단위 테스트는 실제로 그 동작을 취해 구조화 된 패턴으로 형식화하고 저장하여 테스트를 쉽게 다시 실행할 수 있도록합니다. 수동 테스트 대신 "적절한"단위 테스트 사례를 작성하는 경우 시간이 걸리거나 경험에 따라 시간이 덜 걸리며 반복해서 반복 할 수 있습니다.

수년 동안, 나는 사람들이 코드에 대한 단위 테스트를 작성해야한다고 설득하려고 노력했습니다. 테스트를 먼저 작성 했든 (TDD에서와 같이) 기능을 코딩 한 후에도 항상 코드에 대한 단위 테스트를 수행 할 때의 모든 이점을 설명하려고했습니다. 아무도 나에게 동의하지 않았다. 당신은 분명한 것에 동의하지 않으며, 똑똑한 사람이라면 단위 테스트와 TDD의 이점을 보게 될 것입니다.

단위 테스트의 문제점은 행동 변경이 필요하며 사람들의 행동을 변경하기가 매우 어렵다는 것입니다. 말로, 많은 사람들이 당신에게 동의하게 할 것이지만, 그들이하는 방식에 많은 변화가 보이지는 않을 것입니다.

그렇게함으로써 사람들을 설득해야합니다. 당신의 개인적인 성공은 당신이 가질 수있는 모든 주장보다 더 많은 사람들을 끌어들일 것입니다. 그들이 당신이 단위 테스트 또는 TDD에 대해서만 말하는 것이 아니라, 당신이 설교하는 것을하고 있고 성공하면, 사람들이 당신을 모방하려고 시도 할 것입니다.

또한 단위 테스트를 처음으로 작성하는 사람이 없으므로 리드 역할을 수행해야하므로 수행 방법, 방법 및 사용 가능한 도구에 대해 코치해야 할 수도 있습니다. 학생들이 첫 번째 시험을 작성하는 동안 도와주고, 스스로 작성하는 시험을 검토하며, 자신의 경험을 통해 배운 트릭, 숙어 및 패턴을 보여줍니다. 잠시 후, 그들은 스스로 혜택을보기 시작하고, 유닛 테스트 나 TDD를 툴박스에 통합하기 위해 그들의 행동을 바꿀 것입니다.

밤새 변화는 일어나지 않지만 약간의 인내심으로 목표를 달성 할 수 있습니다.

테스트 중심 개발의 주요 부분은 테스트 가능한 코드 작성입니다. 처음에는 일종의 타협처럼 보이지만 테스트 가능한 코드는 궁극적으로 모듈 식이고 유지 관리 가능하며 읽을 수 있습니다. 여전히 사람들을 설득하는 데 도움 이 필요한 경우 단위 테스트의 장점에 대한 간단한 프레젠테이션입니다.

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

대신 통합 테스트를 개선하기 위해 노력하는 것이 좋습니다. 단위 테스트없이 작성하는 것이 더 간단한 많은 코드가 있으며 QA가 요구 사항 문서에 대해 기능의 유효성을 검사 할 수 있으면 완료됩니다. 배송하십시오.

내 생각에 고전적인 예는 GridView에 연결된 ASPX 페이지에 포함 된 SqlDataReader입니다. 코드는 모두 ASPX 파일에 있습니다. SQL이 저장 프로 시저에 있습니다. 단위 테스트는 무엇입니까? 페이지가 수행해야 할 작업을 수행하는 경우 자동화 할 무언가를 갖도록 실제로 여러 계층으로 다시 디자인해야합니까?

단위 테스트의 가장 좋은 점 중 하나는 코드를 테스트하는 것이 쉬워진다는 것입니다. 테스트없이 생성 된 기존 코드는 단위 테스트 용이 아니기 때문에 전자 메일처럼 클래스 내부에서 구성하기 어려운 개체, 클래스간에 높은 수준의 연결을 갖는 것은 드문 일이 아니기 때문에 항상 어려운 문제입니다. 서비스 참조 전송 등. 그러나 이것이 당신을 실망시키지 않도록하십시오! 단위 테스트 작성을 시작하면 전반적인 코드 디자인이 향상되고 테스트를 많이할수록 응용 프로그램을 중단하거나 버그를 도입 할 염려없이 더 많은 변경을 할 수 있습니다. .

코드를 단위 테스트하는 데는 몇 가지 이유가 있지만 시간이 지남에 따라 테스트에 소요되는 시간이 코드를 작성하는 가장 좋은 이유 중 하나라는 것을 알 수 있습니다. 방금 전달한 시스템에서 시스템을 수동으로 테스트하는 것보다 테스트에 더 많은 시간을 소비한다는 주장에도 불구하고 자동화 된 단위 테스트를 수행해야한다고 주장했습니다. 모든 단위 테스트를 완료 한 후 10 분 이내에 400 개가 넘는 테스트 사례를 실행했으며 코드를 약간 변경해야 할 때마다 버그없이 코드가 여전히 작동하는지 확인하는 데 10 번이 걸렸습니다. 의사록. 400 개 이상의 테스트 사례를 직접 실행하는 데 소요되는 시간을 상상할 수 있습니까?

자동화 된 테스트 (단위 테스트 또는 승인 테스트)와 관련하여 모든 사람은 수동으로 수행 할 수있는 작업을 코딩하는 데 낭비되는 노력이라고 생각합니다. 자동화 된 테스트의 가장 좋은 부분은 노력없이 여러 번 실행할 수 있으며 두 번째 또는 세 번째 실행 후에 낭비한 시간과 노력 이 이미 지불 된 것입니다.

마지막 조언 중 하나는 코드를 단위 테스트 할뿐만 아니라 테스트를 먼저 시작하는 것입니다 (자세한 내용은 TDD 및 BDD 참조)

단위 테스트는 코드를 리팩토링하거나 다시 작성할 때 특히 유용합니다. 단위 테스트 범위가 양호하면 안심하고 리팩토링 할 수 있습니다. 단위 테스트가 없으면 아무것도 깨지 않았는지 확인하기가 어렵습니다.

한마디로-네. 그들은 모든 노력의 가치가 있습니다 ... 테스트는 하루가 끝날 무렵에도 여전히 코드이며 일반적인 코드 증가와 마찬가지로 유지 관리 가능하고 지속 가능한 테스트를 위해 리팩터링해야합니다. GOTCHAS의 톤이 있습니다! 단위 테스트에 관해서는, man oh man oh man, 아무것도, 그리고 아무것도 의미하지 않으며, 개발자가 풍부한 단위 테스트보다 더 자신있게 변경을 할 수 있음을 의미합니다.

저는 현재 프로젝트를 진행하고 있습니다. 그것은 다소 TDD이며, 대부분의 비즈니스 규칙은 테스트로 캡슐화되어 있습니다. 현재 약 500여 개의 단위 테스트가 있습니다. 이 지난 반복에서는 데이터 소스와 데스크톱 응용 프로그램이 해당 데이터 소스와 인터페이스하는 방식을 개선해야했습니다. 며칠이 걸렸는데, 내내 방금 유닛 테스트를 계속해서 내가 무엇을 깨뜨 렸는지 고쳤습니다. 변경하십시오. 테스트를 빌드하고 실행하십시오. 파산 한 것을 고치세요. 세척, 헹굼, 필요에 따라 반복하십시오. 전통적으로 며칠 동안 QA와 보트에 많은 스트레스를 받았던 것은 짧고 즐거운 경험이었습니다.

미리 준비하고 약간의 추가 노력을 기울이면 핵심 기능 / 기능으로 문제를 해결해야 할 때 나중에 10 배를 지불합니다.

나는이 책을 샀다-그것은 xUnit Testing에 대한 성경 지식이다-아마도 내 선반에서 가장 많이 언급 된 책들 중 하나 일 것이고, 나는 매일 그것을 참고한다 : 링크 텍스트

때때로 나 자신 또는 동료 중 한 명이 약간 모호한 버그의 맨 아래에 도달하는 데 몇 시간을 소비하며 일단 버그의 원인이 발견되면 코드가 단위 테스트되지 않은 시간의 90 %를 발견합니다. 개발자가 시간을 절약하기 위해 코너를 자르고 있기 때문에 단위 테스트가 존재하지 않지만이 문제와 더 많은 디버깅이 필요하지 않습니다.

단위 테스트를 작성하는 데 적은 시간이 걸리면 향후 디버깅 시간을 절약 할 수 있습니다.

나는 잘 문서화되지 않고 끔찍하며 큰 코드베이스의 유지 보수 엔지니어로 일하고 있습니다. 코드를 작성한 사람들이 단위 테스트를 작성했으면합니다.
프로덕션 코드를 변경하고 업데이트 할 때마다 일부 조건을 고려하지 않은 버그가 발생할 수 있습니다.
그들이 테스트를 작성하면 코드베이스를 더 쉽고 빠르게 변경할 수 있습니다 (동시에 코드베이스가 더 나은 상태에있을 것입니다).

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

단위 테스트는 그만한 가치가 있습니다. 불행히도 구현하기 어려운 어려운 시나리오를 선택했습니다.

유닛 테스트의 가장 큰 장점은 처음부터 사용할 때입니다. 클래스를 구현하기 전에 유닛 테스트를 작성하기에 운이 좋았던 소수의 선별 된 소규모 프로젝트에서 인터페이스가 이미 완성되었습니다. 포인트). 적절한 단위 테스트를 통해 클래스가 아직 초기 단계에 있고 미래에 의심 할 여지없이 통합 될 복잡한 시스템 근처에있는 동안 버그를 찾아 수정하게됩니다.

소프트웨어가 견고한 객체 지향적이라면 너무 많은 노력없이 수업 수준에서 단위 테스트를 추가 할 수 있습니다. 운이 좋지 않은 경우에도 가능하면 단위 테스트를 통합해야합니다. 새로운 기능을 추가 할 때 새로운 인터페이스는 명확한 인터페이스로 잘 정의되어 있으며 단위 테스트를 통해 삶을 훨씬 쉽게 만들 수 있습니다.

"코드 기반이 쉬운 테스트에 적합하지 않다"는 말이 코드 냄새의 첫 징후입니다. 단위 테스트 작성은 코드의 테스트 가능성을 높이기 위해 일반적으로 코드를 다르게 작성하는 것을 의미합니다. 이것은 테스트를 작성해야했던 코드를 작성하면서 수년 동안 보았 듯이 더 나은 디자인을 강요했기 때문에 좋은 견해입니다.

나도 몰라. 많은 장소에서 단위 테스트를 수행하지는 않지만 코드의 품질은 좋습니다. Microsoft는 단위 테스트를 수행하지만 Bill Gates는 프레젠테이션에서 블루 스크린을 제공했습니다.

나는 주제에 관한 매우 큰 블로그 게시물을 썼습니다. 단위 테스트만으로는 가치가 없으며 마감일이 가까워지면 일반적으로 줄어 듭니다.

"테스트 후"검증 관점에서 단위 테스트에 대해 이야기하는 대신 구현 전에 스펙 / 테스트 / 아이디어를 작성하려고 할 때 발견 된 실제 값을 살펴 봐야합니다.

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

첫 개발 테스트로 인생이 바뀌는 방법

예-단위 테스팅은 확실히 노력할 가치가 있지만,은 총알이 아님을 알아야합니다. 단위 테스팅은 작동하며 테스트를 업데이트하고 코드 변경과 관련성을 유지하기 위해 노력해야하지만 제공되는 가치는 여러분이해야 할 노력의 가치가 있습니다. 변경 코드 후에 테스트를 실행하여 비결은 테스트하는 작업 단위 또는 스캐 폴딩 테스트 요구 사항 및 단위 테스트가 실제로 기능 테스트 등인 경우에 너무 매달리지 않는 것입니다. 사람들은 몇 시간 동안이 물건에 대해 논쟁 할 것입니다 결국 코드를 ​​작성하는 것보다 테스트하는 것이 코드를 작성하는 것보다 낫다는 것이 현실입니다. 다른 공리는 수량이 아닌 품질에 관한 것입니다. 1000 '의 코드베이스를 보았습니다. 나머지는 실제로 특정 도메인의 비즈니스 규칙 등과 같은 유용한 도메인이나 특정 도메인을 테스트하지 않으므로 본질적으로 의미가없는 테스트입니다. 또한 코드 범위가 30 % 인 코드베이스를 보았지만 코드의 핵심 기능을 테스트하고 코드 사용 방법을 표현할 때 테스트는 관련성 있고 의미가 있으며 정말 훌륭했습니다.

새로운 프레임 워크 나 코드베이스를 탐색 할 때 제가 가장 좋아하는 요령 중 하나는 작동 방식을 발견하기위한 단위 테스트를 작성하는 것입니다. 건조한 문서를 읽는 대신 새로운 것에 대해 더 많이 배울 수있는 좋은 방법입니다. :)

나는 최근에 직장에서 똑같은 경험을했으며 대부분의 이론적 이점을 알고 있지만 그 이점을 구체적으로 판매해야한다는 것을 알았습니다. 그래서 내가 사용한 점은 다음과 같습니다 (성공적으로).

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

그리고 큰 것 ...

• 단위 테스트가 필요하지는 않지만 다른 사람이 들어 와서 완전히 이해하지 않고 코드를 수정하면 실수를 저지르는 많은 실수를 잡을 수 있습니다.

나는 몇 년 전에 TDD를 발견했고, 그 이후로 모든 애완 동물 프로젝트를 작성했습니다. 프로젝트를 함께 진행하는 데 걸리는 시간과 거의 같은 시간이 걸리는 것으로 추정했지만 최종 제품에 대한 확신이 높아져 성취감을 낼 수 없었습니다.

또한 디자인 스타일을 향상시키고 (모두를 모의해야 할 경우 훨씬 더 인터페이스 지향적 임) 상단 글의 녹색 글이 "코딩 변비"에 도움이된다고 생각합니다. 다음에 글을 쓰거나, 어려운 일을한다면 작게 쓸 수 있습니다.

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

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

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

리포지토리에서 업데이트 할 때마다 새로운 기능으로 인해 고장난 테스트를 업데이트하는 데 몇 시간을 소비하는 것은 생산 적이지도 재미도 없습니다.

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

단위 테스트는 한 개발자가 자신의 머리에 넣을 수있는 것보다 큰 프로젝트에서 많은 도움이됩니다. 체크인하기 전에 단위 테스트 스위트를 실행하고 무언가를 깨뜨 렸는지 발견 할 수 있습니다. 이렇게 하면 다른 사람이 체크인 한 버그를 수정하기를 기다리거나 변경 사항을 되 돌리는 번거 로움으로 인해 약간의 작업을 수행 할 수 있도록 엄지 손가락을 앉아서 비틀어 야하는 경우가 많이 줄어 듭니다 . 또한 리팩토링에서 매우 유용하므로 리팩토링 된 코드가 원래 코드가 수행 한 모든 테스트를 통과했는지 확인할 수 있습니다.

단위 테스트 스위트를 사용하면 나머지 기능을 그대로 유지하면서 코드를 변경할 수 있습니다. 큰 장점입니다. 새로운 기능을 코딩 할 때 단위 테스트 sutie 및 회귀 테스트 스위트를 사용합니까?

나는 대다수와 반대되는 견해에 동의합니다. 단위 테스트를 작성하지 않아도됩니다. 특히 프로토 타입이 많은 프로그래밍 (예 : AI)은 단위 테스트와 결합하기가 어렵습니다.