회사에서 자동 테스트가 계속 실패하는 이유는 무엇입니까?

우리 회사에서 개발자 자동화 테스트를 여러 번 소개하려고 노력했습니다. QA 팀은 Selenium을 사용하여 UI 테스트를 자동화하지만 항상 단위 테스트 및 통합 테스트를 도입하고 싶었습니다. 과거에는 시도 할 때마다 첫 달이나 두 달 동안 모두가 흥분했습니다. 몇 달 후 사람들은 단순히 그 일을 그만 두었습니다.

몇 가지 관찰과 질문 :

1. 자동 테스트가 실제로 작동합니까? 다른 회사에서 근무하던 대부분의 동료들은 자동화 된 테스트 전략을 구현하지 못했습니다. 나는 실제로 그것을 사용하고 그것에 대해 이야기하지 않는 실제 소프트웨어 회사를 아직 보지 못했습니다. 많은 개발자들이 자동화 된 테스트를 이론 상으로는 훌륭하지만 실제로는 작동하지 않는 것으로보고 있습니다. 우리의 비즈니스 팀은 개발자들이 30 %의 추가 시간 (최소한 그렇게 말한)의 비용으로도 그렇게하기를 원합니다. 그러나 개발자는 회의론자입니다.

2. 자동화 된 테스트를 올바르게 수행하는 방법을 실제로 아는 사람은 없습니다. 예, 우리는 모두 인터넷에서 단위 테스트 예제를 읽었지만 큰 프로젝트에 사용하는 것은 전혀 다른 것입니다. 주요 원인은 데이터베이스 또는 사소하지 않은 것을 조롱 / 스터 빙하는 것입니다. 실제 테스트를 작성하는 것보다 조롱하는 데 더 많은 시간을 소비하게됩니다. 그런 다음 코드보다 테스트를 작성하는 데 시간이 오래 걸리면 포기하는 것입니다.

3. 복잡한 데이터 중심 웹 응용 프로그램에서 사용되는 단위 테스트 / 시스템 통합 테스트에 대한 좋은 예가 있습니까? 오픈 소스 프로젝트가 있습니까? 우리의 응용 프로그램은 데이터 중심이지만 많은 도메인 논리를 가지고 있습니다. 어느 시점에서 리포지토리 접근 방식을 시도하여 단위 테스트에 매우 적합하다는 것을 알았지 만 데이터 액세스를 쉽게 최적화 할 수있는 가격에 도달했으며 또 다른 복잡성을 추가했습니다.

20 명의 숙련 된 개발자가 수행 한 대규모 프로젝트가 있습니다. 이것은 단위 테스트 / 통합 테스트를 도입하기에 이상적인 환경 인 것 같습니다.

왜 우리에게 효과가 없습니까? 회사에서 어떻게 작동하게 했습니까?

단위 테스트를 수행하는 데있어 가장 어려운 부분은 징계를 먼저 / 초기 작성하는 것입니다. 대부분의 개발자는 코드를 살펴 보는 데 익숙합니다. 또한 코드 테스트를 작성하는 방법을 파악하려고 할 때 개발 프로세스가 일찍 느려집니다. 그러나 테스트에 익숙해지면 속도가 빨라집니다. 그리고 필기 테스트로 인해 코드의 초기 품질이 더 높아집니다.

시작할 때 테스트를 작성하십시오. 처음에 조롱 / 스터 빙에 대해 너무 걱정하지 마십시오. 테스트를 간단하게 유지하십시오. 테스트는 코드이며 리팩터링해야합니다. 테스트하기 어려운 경우에도 이러한 라인을 따라 설계 될 수도 있습니다. TDD는 대부분의 디자인 패턴 (내 경험, 특히 팩토리 패턴)을 사용합니다.

테스트가 가시성을 확보했는지 확인하십시오. 코드를 검토하는 동안 릴리스 프로세스에 통합하십시오. 발견 된 모든 버그는 테스트를 받아야합니다. 이것들은 TDD가 빛나는 곳입니다.

다음은 유용한 것으로 알려진 몇 가지 리소스입니다.

http://misko.hevery.com/attachments/Guide-Writing%20Testable%20Code.pdf

http://www.agitar.com/downloads/TheWayOfTestivus.pdf

편집하다:

테스트를 작성할 때 명심해야 할 것이 있습니다. 코드 구현에 대해 아무것도 지정하지 않고 동작 만 지정하려고합니다. 코드를 작성할 때 항상 테스트합니다. 디버그 문 등으로 실행하려고합니다. 작문 시험은이를 공식화하고 보유한 시험 기록을 제공합니다. 그렇게하면 개발 과정의 중간에 기억했던 테스트 사례를 우연히 건너 뛰지 않고 자신있게 기능을 확인할 수 있습니다.

여러면에서 나는 당신의 팀에 동의합니다.

1. 대부분의 단위 테스트는 가치가 있습니다. 대부분의 테스트는 너무 단순 해 보입니다.

2. 작동 코드보다 테스트 가능한 코드를 작성하는 것이 훨씬 어렵습니다. 코드 / 디자인 품질 자체에 비해 작동하도록 믿는 개발자 커뮤니티의 비율이 상당합니다. 품질 코드가 무엇인지 모르는 사람도 훨씬 더 많습니다.

3. 실제 코드 자체보다 단위 테스트 코드를 작성하는 데 훨씬 오래 걸릴 수 있습니다.

4. 보다 복잡한 코드 (예 : 실제로 철저한 테스트에 관심이있는 것)를 적절하게 테스트하는 방법을 알아내는 것은 많은 개발자 기능을 넘어선 것입니다.

5. 단위 테스트를 유지하는 데 시간이 너무 오래 걸립니다. 작은 변화는 큰 파급 효과를 가질 수 있습니다. 자동화 된 단위 테스트의 주요 목표는 변경 사항이 코드를 위반했는지 확인하는 것입니다. 그러나 깨지는 결과의 99 %는 코드가 아니라 테스트입니다.

위의 모든 문제가 있어도 코드를 변경하고 테스트 자동화보다 예상치 못한 문제가 발생하지 않을 것이라는 확신을 가질 수있는 더 좋은 방법은 여전히 ​​없습니다.

위의 일부는 단위 테스트의 교과서로 가지 않으면 어느 정도 완화 될 수 있습니다.

많은 유형의 설계 / 애플리케이션은 모듈 / 패키지 레벨에서 테스트를 자동화하여 더 잘 테스트됩니다. 내 경험상 대부분의 코딩 오류는 클래스의 코드가 잘못 코딩 되었기 때문에가 아니고 코더가 해당 클래스가 다른 클래스와 어떻게 작동하는지 이해하지 못했기 때문입니다. 나는 이런 종류의 테스트에서 많은 돈을 벌었습니다. 그러나이 테스트는 다시 한 번 단위 (클래스 레벨) 테스트보다 작성하기가 어렵습니다.

실제로 개발자가 프로세스를 믿는지 여부에 달려 있습니다. 만약 그렇다면, 그들은 좋은 단위 테스트를 작성하고 오류를 조기에 발견하며 지지자가 될 것입니다. 그렇지 않은 경우 단위 테스트는 대체로 쓸모가 없으며 오류가 없으며 단위 테스트 이론이 쓸모가 없다는 것이 사실입니다.

결론은 내가 2 개월 이상 동안 완전 자동화 된 자동 단위 테스트 접근 방식을 본 적이 없다는 것이지만, 자동화 된 단위 테스트에 대한 아이디어는 여전히 테스트가 필요한 부분에 선택적이지만 여전히 지속됩니다. 이 접근 방식은 비평가가 훨씬 적은 경향이 있으며 일부 개발자가 아닌 모든 개발자가 더 많이 받아들입니다.

주요 원인은 데이터베이스를 조롱하거나 스터 빙하는 것 또는 단순하지 않은 것입니다.

그리고 당신의 문제가 있습니다.

모두가 단위 테스트를 환경에 통합하는 방법에 대해 좋은 지적을합니다. 사람들이 실질적인 가치와 "고착"을 볼 수있을 정도로 강요하는 방법. 그러나 너무 고통스럽고 혜택을 제공하지 않으면 고수하지 않습니다.

데이터베이스를 제거하는 것은 간단합니다. 인터페이스가 결과를 제공하기 위해 일부 DB 백업으로 이동하는 대신 간단한 하드 코딩 된 객체를 넣습니다. 그렇게 할 수 없다면 디자인 / 아키텍처에 문제가있는 것입니다. 코드는 데이터베이스로 이동한다고 가정하거나 데이터베이스를 변경할 인터페이스 추상화가 없다고 가정합니다.

이것은 단순히 테스트 / 품질 문제가 아닙니다. DB 공급자를 변경하거나 클라우드로 이동하거나 연결되지 않은 모바일 앱을 지원하자마자 디자인이 실패합니다. 가장 간단한 융통성 사례를 지원할 수없는 경우에는 비즈니스에서 필연적으로 필요한보다 복잡한 사항을 지원할 수 없습니다.

작고 자동화하기 쉽고 높은 가치로 시작해야합니다. 달콤하고 매달린 과일을 잡아 당기면 공정을 판매 할 수 있습니다. 늦은 밤이나 주말에 누군가를 어떻게 구했는지 보여줍니다. 그런 다음 거기서 확장 할 수 있습니다.

자동화 된 테스트를 제대로 수행하려면 리소스 및 전도자이며 상위 관리자로부터 구매 한 사람이 필요합니다.

자동화 된 테스트 개발을 다른 민첩한 프로젝트처럼 취급하십시오. 완료된 테스트를 정기적으로 생성하십시오.

코멘트에서 추가 : 그것은 더 많은 관리 문제입니다. 코드가 문서화되기 전에 "완료"된 것으로 간주됩니까? 체크인하기 전에? 단위 테스트를 포함하고 통과하기 전에?

당신이 이것에 접근하는 방법은 실제로 당신의 역할에 달려 있습니다. 당신은 동료입니까? 그렇다면 다른 사람들이 코드를 쉽게 재사용하고 유지 관리하는 방법을 보여주십시오. 당신은 리드입니까? 코드 문제가 가장 많은 프로그래머를 선택하고 해당 문제를 피하기 위해 테스트를 추가하도록 도와주십시오. 당신은 보스입니까? "단위 테스트가 통과 할 때까지 코드가 수행되지 않는 표준으로 설정하십시오.

이 기본 규칙을 따르십시오. 테스트 :

1. 정기적으로 실행해야합니다! 모든 빌드, 체크인 전후에 또는 매일 아침마다 테스트를 실행할 수 있습니다. 자동 트리거는 수동 트리거 보다 선호 됩니다. 이론적으로는 팀의 모든 사람이 테스트를 실행하도록 책임을 질 수 있기 때문에 자동화되지 않은 경우 자주 발생하지 않을 수 있습니다! 테스트를 충분히 자주 실행하지 않으면 버그가 너무 늦어서 깨진 테스트가 많이 발생하여 2 단계로 이어집니다.

2. 이제 정기적으로 실행되는 테스트 가 방해 가되지 않는 경우에만 성공할 것 입니다. 우리는 테스트를 의미합니다.

   에이. 그들이 제공하는 가치를 (주관적으로) 실행하는 데 너무 오래 걸리지 않아야합니다! 테스트 속도가 빨라집니다. 사람들이 시간을 낭비하게 될 테스트를 체크인하지 못하게하십시오!

   비. 신뢰할 수 없어야합니다. 가능하면 다중 스레드 테스트를 피하십시오. 다른 코드와 마찬가지로 테스트에 엔지니어링 사례를 적용하십시오. 특히 테스트 코드를 검토하십시오!

   씨. 테스트 한 실제 코드보다 수정 및 유지 관리가 어렵지 않아야합니다. 코드베이스를 조금만 바꾸면 10 가지 테스트를 수정해야한다면 코딩 속도가 빨라질 것입니다.

마지막으로 규칙 번호 3입니다. 규칙 2에서와 같이 테스트는 음수 값을 제공하지 않아야 할뿐만 아니라 양수 값을 제공해야합니다. 테스트 ...

3. 그들이 실패 할 때 실제로 당신에게 관심 있는 것을 말하고 있어야합니다 ! (분명한 오류 메시지가있는 테스트가 없거나 'Windows 2008 컴퓨터에서 테스트를 실행하는 것을 잊어 버렸습니다'와 같은 우스꽝스러운 불만을 표시하는 경우 만 있습니다!).

규칙 # 3을 위반하는 한 가지 대중적인 방법 은 잘못된 것을 테스트하는 것입니다 . 때로는 테스트가 너무 크거나 초점이 맞지 않기 때문입니다. 그러나 일반적으로 고객이 관심을 갖는 것을 테스트하지 않고 관련이없는 구현 세부 사항을 테스트하는 것입니다. (그러나 때로는 구현 세부 사항을 테스트하면 효율적인 테스트도 가능합니다. IMO는 어느 것을 결정하는 연습이 필요합니다.)

결론 :이 기본 규칙은 지속 가능한 테스트 원칙 의 일반적인 방향을 가리키며 , 이는 당신이 절망적으로 갈망하는 것입니다. 테스트 할 때이 테스트가 실제로 지속 가능하고 유지 가능한지 자문하십시오. 생각해 내다:

• 테스트가 지속 가능하지 않으면 사용이 중단되어 노력이 낭비됩니다
• 테스트가 지속되지 않으면 테스트를 중단하고 팀의 테스트가 더 이상 중단됩니다! 그리고 마지막 요점 :

테스트는 실제로 어렵다. 당신은해야 당신이 쓰기 테스트를 시작할 때 팀의 테스트는 기본적으로 빨아 것으로 기대 . 낙심하지 마십시오. 마십시오 당신은 그들이 빨아 통지 및 지속 때마다, 기존 테스트를 던져.

1. 정말 작동합니까?

네, 그렇습니다-제대로 수행되면. 요점은 엔지니어가 새로운 기능을 구현 한 후 테스터가 자동 스크립트를 조정하고 확장해야한다는 것입니다.

2. 실제로 자동 테스트를 제대로 수행하는 방법을 모르거나 경험 한 사람은 없습니다.

컨설턴트에게 문의하십시오 (어떻게 제대로 수행되는지 아는 사람). 또는 더 많은 시간을 투자하십시오. 대안은 동일한 테스트를 수동으로 수행하는 더 큰 테스트 팀을 두는 것입니다 (오류가 발생하기 쉽습니다).

3.우리는 20 명의 숙련 된 개발자들이 작업하는 큰 프로젝트를 가지고 있습니다. 따라서 단위 테스트 / 통합 테스트를 도입하기에 좋은 환경이어야합니다. 왜 우리에게 효과가 없습니까? 회사에서 어떻게 작동하게 했습니까?

그들이 단위 테스트를 거부한다면 나는 "좋은 경험이 풍부한 개발자"라고 부르지 않을 것입니다. 테스트의 긍정적 인 이점 (단위 및 통합 테스트 모두)에 대한 많은 훌륭한 기사가 있으며, 결국에는 회사의 버그 비용이 얼마나되는지 설명합니다 . 예를 들어, 품질이 중요한 회사에서 일하므로 단위 및 통합 테스트를 피할 수 없습니다. 단위 테스트만으로 버그 수를 30 % 줄였다는 내용의 기사를 쉽게 찾을 수 있습니다! (실제로, 평균 30 %이지만 20-90 % 범위에 있지만 여전히 많이 있습니다.)

회사에서 업무를 수행하려면 컨설턴트를 고용하거나이 작업을 선임 엔지니어에게 할당하십시오 (시간이 오래 걸림). 그런 다음 모든 사람이 규칙을 따르도록 강요하십시오.

자동화 된 테스트를 도입하지 못하는 데는 여러 가지 이유가 있습니다. 프로그래머가 코딩 습관을 바꾸지 않는 경향이 있고 단위 테스트를 완전히 수용 할 수 없다는 사실로 귀결됩니다.

자동화 된 테스트를 시작하려는 많은 사람들이 기존 코드 기반을 소개하려고합니다. 기존 애플리케이션의 많은 기능을 한 번에 테스트하는 통합 테스트를 작성하려고합니다. 이러한 통합 테스트는 유지하기에는 너무 어렵고 비용이 많이 듭니다. 조언 : 새로운 코드베이스에 대한 자동화 된 테스트를 소개하십시오.

단위 테스트는 자동화하기에 좋은 테스트입니다. 위의 모든 것 (통합 테스트, 구성 요소 테스트, 시스템 테스트)도 자동으로 테스트 할 수 있지만 비용-이익 비율은 한 번에 더 많은 기능을 테스트할수록 급격히 떨어집니다. 단위 테스트가 잘 안된 기능에 대해 이러한 테스트를 작성하면이 부정적인 영향이 증폭됩니다. 조언 : 단위 테스트 수준에서 자동 테스트를 소개하고 견고한 단위 테스트 기반에서 자동 통합 테스트를 구축하십시오 .

위의 시점에서 자동화 테스트의 성공 여부는 단위 테스트의 효과에 달려 있습니다. 단위 테스트를 통해 생산성이 있다고 생각되면 효과적인 단위 테스트가 있습니다. 사람들이 단위 테스트를 시작할 때 기존 코드와 코딩 습관을 단위 테스트에 맞게 개조하는 경향이 있습니다. 아이러니하게도 이것은 단위 테스트를 배우는 가장 어려운 방법입니다. 또한 단위 테스트를 수행하려면 코딩 방식을 변경해야합니다 (예 : SOLID 원칙 적용 ). 대부분의 프로그래머는 희박한 곡선이 너무 가파르다 고 생각하고 단위 테스트를 테스트 할 수없는 코드로 둘러 싸기가 어색하기 때문에 단위 테스트 작성을 곧 중단합니다. 조언 : 새로운 코드로 기초부터 단위 테스트를 배우고 코딩 습관을 바꿔야한다는 사실을 다루십시오.

다른 많은 요소가 있지만 대부분의 프로그래머에게는 코딩 방식을 변경하는 것이 번거 롭다는 것을 알았습니다. 테스트없이 작성된 코드는 다르게 보입니다. 테스트 가능한 디자인으로 코드를 짜지 못하면 효과적인 단위 테스트를 작성하지 못할 가능성이 큽니다. 이는 효과적인 자동화 테스트의 기반을 파괴합니다.

나는 그것을 스스로 경험했으며 이제 자동화 된 테스트를 성공적으로 도입 한 회사에서 일하게되어 기쁘다. 다른 요소에 대해 더 많이 쓸 수는 있지만 코딩 습관과 단위 테스트가 가장 중요하다고 생각합니다. 운 좋게도 나보다 더 많은 경험이 있고 노하우로 책을 채우는 사람들이 있습니다. 이 책 중 하나는 Microsoft 기술 스택을 사용하고 있기 때문에 .NET의 Brownfield Application Development입니다 .

위의 답변에서 명확하게 다루지 않은 한 가지는 단위 테스트가 본질적으로 공공재이며 개인 비용이라는 것입니다. 여기에 블로그 게시물을 작성했습니다 .

무엇을 내려 오는 것은 동안이다 테스트 스위트는 팀 또는 개인 개발자 혜택, 테스트를 작성하는 것은 그 일을하는 것과 비용, 대부분의 시간입니다.

간단히 말해, 테스트 작성이 어떻게 든 시행 되지 않는 한 ( 위의 답변에 여러 가지 다른 방법이 나열되어 있지 않다면) 개별 개발자가이를 수행 할 이유가 없습니다.

내가 근무한 한 회사에서 단위 테스트 작성은 기능을 제공하는 데 필요한 부분이었습니다. 단위 테스트가 커밋 또는 새로운 기능의 일부가 아닌 한 새로운 코드는 승인되지 않았습니다. 개발자가 제공 한 모든 "작업"에 대한 간단한 코드 검토가있었습니다. 직장에서 유사한 정책을 구현하는 것이 좋습니다.

비즈니스가 개발자보다 더 많은 테스트를 거는 것이 흥미 롭습니다! 가장 큰 도전은 개발자의 변화에 ​​대한 저항을 극복하는 것입니다. 그들은 단위 테스트를 포함하기 위해 자신의 작업에 대한 이해를 재정의해야합니다.

개발자가 이러한 테스트 작성에 대한 저항을 극복 할 수 있도록 초기 단위 테스트 성공 이상의 도움을 줄 수있는 것은 없습니다. 그들이 새로운 것을하도록 강요한다면, 거의 보장 된 보상으로 무언가를 먼저 밀어야합니다.

@SkipHuffman이 이것에 손을 대었지만, 나는 그것을 똑바로 말할 것입니다. 어떤 것들은 다른 것보다 자동화 된 테스트에 훨씬 더 적합합니다. 첫 번째 단계에서는 데이터베이스 나 UI를 테스트 하지 않습니다 . 데이터베이스의 입력은 설정 및 해제가 매우 어려울 수 있습니다. UI 출력 테스트는 테스트와 전혀 관련이없는 모양과 느낌의 변경으로 인해 빠르게 중단되는 경향이 있습니다.

내가 "미들웨어"라고 부르는 것은 단위 테스트에 완벽합니다. 입력 및 출력 조건을 명확하게 정의한 코드입니다. DRY 원칙을 따르지 않으면 (반복하지 마십시오) 응용 프로그램 고유의 반복되는 문제를 해결하기 위해 몇 가지 작은 클래스 나 함수를 작성했을 것입니다.

단위 테스트는 기존 내부 구성 요소의 변경 위험을 제한하는 훌륭한 도구입니다. 오랫동안 작동 한 내부 구성 요소를 변경하기 전에 장치 테스트를 작성하십시오. 이 테스트는 현재 작동중인 기능이 보존되었음을 증명합니다. 변경을 수행하고 모든 단위 테스트를 통과하면 "다운 스트림"이 손상되지 않은 것입니다. 다운 스트림 문제를 발견하면 이에 대한 단위 테스트를 추가하십시오!

Ron Heifitz는 "사람들이 가지고있는 가치의 갈등을 해결하거나 사람들이 대변 하는 가치와 그들이 직면하는 현실 사이의 격차를 줄이려한다"고 말했다. 인간의 변화에 ​​대한 저항을 극복 한 후에는 더 어려운 테스트 영역으로 적절히 분기 할 수 있습니다.

자동 테스트의 한 가지 점은 테스트 할 수있는 코드를 작성해야한다는 것입니다. 이것은 그 자체로는 나쁜 것이 아니며 (실제로 피해야하는 많은 관행을 권장하지 않기 때문에 좋습니다.) 기존 코드에 단위 테스트를 적용하려고하면 기회가 아닙니다. 테스트 가능한 방식으로 작성되었습니다.

싱글 톤, 정적 메소드, 레지스트리, 서비스 로케이터 등과 같은 것들에는 매우 조롱하기 어려운 종속성이 도입됩니다. 데 메타 법칙을 위반하면 코드베이스의 너무 많은 부분이 코드베이스의 다른 부분이 어떻게 작동하는지에 대해 너무 많이 알고있어 깨지기 어려운 숨겨진 종속성을 추가로 발생시킵니다. 이러한 모든 것들은 모듈을 나머지 코드베이스로부터 분리하는 것을 어렵게 만들고, 모듈을 독립적으로 테스트 할 수 없다면 단위 테스트는 많은 가치를 잃게됩니다. 테스트에 실패하면 테스트 대상 장치의 결함 또는 종속 항목 중 하나의 결함으로 인한 것이거나 종속 데이터 소스를 통해 가져온 데이터가 테스트 작성자가 예상 한 것이 아니기 때문입니다. ? 할 수 있다면

단위 테스트를 염두에두고 구축되지 않은 것으로 보이는 대부분의 코드베이스는 본질적으로 테스트 할 수없는 경향이 있습니다. . 단위 테스트를 염두에두고 작성된 코드는 매우 다르게 보입니다.

많은 사람들이 처음으로 단위 테스트를 시작할 때 단위 테스트에 순진한 접근 방식을 취합니다. 기존 코드베이스에 대해 많은 테스트를 작성할 수 있으며 모든 것이 좋을 것이라고 생각하지만 결코 그렇게하지 않습니다. 위에서 언급 한 문제. 그들은 단위 테스트에서 많은 양의 설정을 조정해야한다는 사실을 발견하기 시작했으며 코드에서 분리가 부족하면 테스트 실패의 원인을 추적 할 수 없기 때문에 결과에 의문이 생길 수 있습니다. 또한 시스템 작동 방식에 대한 매우 추상적 인 측면을 보여주는 "영리한"테스트 작성을 시작하는 경향이 있습니다. "영리한"단위 테스트 자체가 잠재적 인 버그 소스이기 때문에 이것은 실패하는 경향이 있습니다. 테스트 한 모듈의 버그로 인해 테스트가 실패 했습니까? 또는 테스트 버그로 인해? 테스트는 매우 흥미롭고 간단해야 버그가 숨겨 질 가능성이 없습니다. 실제로 가장 좋은 테스트는 2 줄을 넘지 않으며, 첫 번째 줄은 테스트 대상 유닛에게 무언가를하도록 지시하는 것이고, 두 번째 줄은 그것이 무엇을했는지 예상 한 것이라고 주장합니다.

팀에서 단위 테스트 채택을 진지하게 고려한다면 기존 프로젝트를 시작하는 것이 현명하지 않습니다. 팀의 기존 프로젝트는 주요 리팩터링 없이는 테스트 할 수 없습니다. 깨끗한 슬레이트가 있으므로 단위 테스트에 대한 학습의 기초로 새 프로젝트를 사용하는 것이 좋습니다. 싱글 톤, 레지스트리 및 기타 숨겨진 종속성에 대한 종속성 주입을 선호하도록 새 코드 기반을 설계 할 수 있으며 구현 대신 인터페이스에 의존하도록 작성할 수 있습니다. 또한 테스트 후 코드를 작성하는 것이 아니라 테스트 된 모듈이 수행하는 것이 아니라 테스트 된 모듈이 의도 한대로 작동하는지 확인하는 단위 테스트를 수행하므로 테스트 할 코드와 함께 테스트를 작성할 수도 있습니다. 사양에서해야 할 일

단위 테스트에 대해 어느 정도 확신을 갖게되면 팀은 기존 코드의 단위 테스트에 장애가 될 결함을 깨닫기 시작할 것입니다. 이때 기존 코드를 리팩토링하여 더 테스트 가능하게 만들 수 있습니다. 야심 차지 말고 한 번에이 작업을 시도하거나 완전히 새로운 시스템으로 교체하려는 시스템을 시도해보십시오. 쉽게 테스트 할 수있는 코드베이스의 비트 (찾을 수없는 비트)를 찾기 만하면됩니다. 모든 종속성 또는 종속성이 분명한 경우) 및 해당 테스트를 작성하십시오. 코드와 함께 테스트를 작성하는 것이 나중에 테스트를 작성하는 것이 바람직하지만 나중에 작성된 테스트조차도 여전히 시작점으로 가치가 있다고 말했습니다. 클래스가 스펙이 말한 것 이외의 작동 방식에 대해 아는 것처럼 테스트를 작성하십시오. 테스트를 실행하고 실패하면 스펙 또는 구현이 잘못되었습니다. 둘 중 하나를 잘못 확인하여 테스트 또는 코드를 적절히 업데이트하십시오.

낮은 매달린 과일을 골라 내면 실제 작업이 시작됩니다. 코드베이스에서 숨겨진 종속성을 찾아서 한 번에 하나씩 수정해야합니다. 이 시점에서 지나치게 야심 차지 말고, 테스트의 장애물이 해결되고 다음 비트로 넘어갈 때까지 한 번에 하나의 모듈을 수행하거나 한 모듈에서 하나의 단일 문제를 고수하십시오.

TL : DR : 대부분의 사람들은 테스트가 쉽다고 생각하고 테스트를 기존 코드에 쉽게 개조 할 수 있습니다. 이러한 가정은 모두 틀렸다. 이 두 가지 사실을 모두 고려하여 프로젝트에 단위 테스트를 받기 위해 프로젝트를 시작하면 성공할 가능성이 높습니다.

• 귀사에서 자동화 된 테스트를 수행 한 경험이있는 사람이 있습니까?

그렇지 않으면 자동화 된 테스트 이니셔티브가 실패 할 수 있습니다. 자동화 된 테스트는 다른 많은 프로그래밍 기술과 같은 기술이며, 경험이없는 사람이 있다면 자동화 된 테스트가 실제 가치 가있는 우수한 자동화 된 테스트인지 또는 나쁜 테스트인지를 쉽게 알 수 없습니다 무작위로 실패 / 빈번한 업데이트 필요 / 실제로 흥미로운 코드를 행사하지 않습니다.

• 누군가가 리더십을 가지고 있습니까? 그들은 변화를 요구할 수 있습니까?

아무도 듣지 않으면 시험이 좋지 않다고해도 문제가되지 않습니다. (리더십의 힘을 공식화 할 필요는 없습니다. 관심있는 팀을 갖는 것도 좋습니다.)

• 자동화 된 테스트를보다 쉽게 ​​구현하고 개발주기에 통합 할 수 있도록 도구와 프로세스를 개발하고 있습니까?

개발자는 게으르다. 원하는 것을 달성하기 쉽도록하고 싶지 않은 것을 달성하기가 더 어려워 야합니다. 테스트 라이브러리가 테스트 설정 및 해제와 관련된 작업, 특히 테스트 데이터베이스 등과 같은 환경 관련 설정을 쉽게 수행 할 수 있도록해야합니다. (데이터베이스 조작은 이러한 의견 중 일부에서 논의되지만주의해서 사용해야합니다. 실제 데이터베이스는 스핀 업하기 쉬워야하며 단위 테스트보다 더 중요하고 효과적인 구성 요소 및 프로세스 라이프 사이클의 상호 작용을 테스트 할 수 있어야합니다. 개별 데이터 접근 자.)

또한 IDE에 테스트 스위트를 시작하는 좋은 방법이 있는지 확인해야합니다. 테스트 스위트를 자주 실행하여 사람들이 테스트에 실패하지 않고 실패 할 때 알 수 있도록해야합니다. 개발자는 피드백에 잘 반응합니다 (예 : 테스트를 마친 경우 변경 사항을 되 돌리는 자동 통합 시스템). 또는 더 나은 긍정적 인 피드백 : 버그를 잡아서 문제를 해결하는 자동화 된 통합 시스템입니다.

첫째, 개발자가 테스트의 가치를 보지 못하면 개발자의 가치 또는 일반적으로 테스트의 가치에 대해 눈이 멀기 때문에 테스트가 가치가 없기 때문일 수 있습니다. 전도자들 중에는 테스트 주도 개발이 실패 할 수 없다고 믿는 경향이 있으며, 게으르고 게으른 개발자들에 의해서는 실패 할 수 있습니다. 나는 이것이 잘못되고 비생산적이라고 생각합니다.

테스트 중심 개발을 소개 받았을 때, 절대 실패하지 않는 방법이 절대 실패하지 않는지 확인하는 테스트를 효과적으로 작성했습니다. 당신은 사랑스러운 녹색 점검과 성취감을 얻기 때문에 처음에는 좋습니다. 나중에 코드를 리팩터링 한 후 수십 개의 화끈한 빨간색 Xes가 있는데, 그 중 코드가 변경된 것, 테스트가 더 이상 유효하지 않으며 코드를 작성하는 데 많은 시간을 허비 한 것 외에는 아무 것도 말하지 않습니다.

당신은 그것을 피하고 싶습니다.

그 이후로, 나는 테스트에 다른 접근 방식을 취했습니다. 대신의 인터페이스 구현 쌍 , 나는이 트리플 인터페이스, 구현, 테스트 . 인터페이스는 동작을 지정하고 구현은 동작을 수행하며 테스트는 동작을 확인합니다.

나는 그것이 명백해 보인다고 생각하지만, 나에게 그것은 당신이 명시된대로 작동한다고 입증 해야하는 코드와 당신이 적절하다고 생각하는만큼 테스트 할 수있는 코드를 구별합니다. 증명해야 할 코드는 외부에 제공하는 인터페이스입니다. 나머지는 당신의 관심사입니다.

이 경우 개발자에게 이러한 종류의 테스트가 적합한 코드의 자연스러운 구분을 볼 수 있는지 묻습니다. 팀 A가 구현하고 팀 B가 사용하는 인터페이스가 있습니까? 이 경우 인터페이스가 예상대로 작동하는지 확인하는 것이 팀 B의 이익입니다. 팀 B에게 테스트를 요청한 다음 팀 A에게 구현이 테스트와 일치하는지 확인하도록 요청하십시오. 그렇지 않은 경우 또는 의도적으로 그렇지 않은 경우 다른 팀과 예기치 않은 변경 사항을 논의하여 준비 할 수 있도록합니다.

이것이 테스트의 가치를 설명 할 것이라고 생각합니다. 그 자체로는 끝이 아니며 사랑스러운 녹색 체크에도 불구하고. 한 개발자가 다른 개발자에게 한 약속을 명시 적으로 밝히고 두 약속을 모두 만족시킬 수 있도록 보장하는 것이 존재합니다.

기존의 대규모 프로젝트에 많은 단위 테스트를 추가하는 것은 어려운 일입니다. 자신에게 적합한 훌륭한 조롱 프레임 워크를 이미 찾았다면 가장 어려운 문제를 해결해야합니다.

기능 / 수정 버그를 추가 할 때 테스트를 추가하는 것이 좋습니다. 가장 쉬운 버그 수정. 버그로 인해 실패한 테스트를 작성한 다음 버그를 수정하십시오. 동시에 당신은 아마도 통과하는 더 간단한 테스트를 작성하게 될 것입니다. 물론 당신은 이것을 위해 작고 쉽게 테스트 된 코드 비트를 사용하고 싶습니다.

사람들이 더 쉬운 것들에 대한 테스트를 작성하는 데 익숙해지기 시작하면 더 테스트가 가능하도록 코드를 작성해야합니다.

또한 테스트의 코드 적용 범위를 측정하는 것이 좋습니다 ( 과거에는 Java에서 cobertura 를 사용했습니다 ). 지속적인 통합 서버가 테스트를 실행하고 정기적으로 (매일 체크인 할 때마다) 메트릭을 생성해야합니다. 동료 개발자가 열렬한 경우 시간이 지남에 따라 적용 범위가 증가하고 일부 사용자의 적용 범위 구멍을 볼 수 있습니다.

긴 게임을해야한다고 생각합니다. 수용 할 수있는 한 가지 방법은 작성한 다음 기능을 철저히 단위 테스트 한 다음 시간이 지남에 따라 버그 수를 추적하는 것입니다. 주요 버그가 조기에 발견되고 (특히이를 테스트 주도 설계와 결합 할 경우) 회귀 횟수가 매우 적어야한다는 것을 희망해야합니다. 1 년 후 일정 기간이 지나면 통계를 유사한 복잡도의 비 단위 테스트 기능과 비교합니다. 새로운 버그와 회귀의 수가 현저히 낮다는 것을 보여줄 수 있다면 재정적으로 정당성을 입증 한 것이며 제품 팀이 무시하기가 더 어려워집니다.

주요 기능에 TDD 및 단위 테스트를 사용할 수있는 상황이있었습니다. 개발 단계가 끝난 후 5 년 이상 단일 버그가보고되지 않았습니다. 새롭고 위험한 개선이 요청되었을 때이를 구현하고 단위 테스트에서 모든 회귀를 포착 할 수있었습니다.

많은 팀들이 단위 테스트의 가치를 크게 과소 평가했다는 점에 대한 강한 견해입니다.

종종 개발자들은 "일을 끝내야"한다는 압력을 받고 있기 때문에 코드 블록이 작동한다는 것을 증명하는 것은 고객에게 충분한 증거입니다. 이는 거의 항상 컨설팅 회사 및 인간 중심 QA에 적용됩니다. 고객이 단위 테스트를 요구하지 않고 라이브 데모를 충분히 시연하는 경우 고객은 결함을 숨길 수있는 코드에 대한 승인에 서명하기 때문에 완전히 실패했습니다.

종종 개발자들은 좌절합니다. 프로그래머가되는 것은 어려운 일입니다. 과제를 끝내고 다음 단계로가는 것은 만족 스럽기 때문에 모두가 서두르고 끝내기를 원합니다. 원래 QA 이후 몇 달 동안 큰 버그가있는 버스에 부딪 칠 때까지. 이 시나리오에서 자동화 된 지속적인 QA는 개발자가 아닌 경영진의 문제입니다 (아마도 초과 근무에 대한 대가를 지불해야 할 것입니다).

그러나 예외가 있습니다

저는 자동화 된 테스트 모델을 수용하는 것이 수행되는 테스트의 "인간"기능이라고 생각합니다. 프런트 엔드를 사용하여 웹 모듈을 테스트하는 경우 Selenium과 같은 도구에도 불구하고 양식을 직접 작성하여 결과를보고 결정 성을 믿을 가능성이 큽니다. 나중에 테스트를 다시 실행하는 것을 잊거나 이전 테스트를 다시 수행하기에는 너무 게으 르기 때문에 나중에 버그가 발견되는 경우가 있습니다. 이를 활용하기 위해 뱅킹 환경 (개인 업무 환경)에서 코드의 강력한 모듈화와 "오래된 코드 수정"에 대한 엄격한 규칙이 허용되는 것으로 입증되었습니다.

대신 개발자가 자동화 된 대용량 데이터 모듈을 개발하는 경우 철저한 단위 테스트를 작성하여 테스트 배치에 제출할 가능성이 높습니다. 외부 XML 데이터 소스에서 변환 된 데이터로 대량의 XML 페이로드를 채우는 것은 사람이 다루기 쉬운 작업이 아니기 때문입니다. 일부 테스트 개발자는 이러한 특정 종류의 테스트를 위해 작고 재미있는 프런트 엔드를 구축하게됩니다. 석사 논문에서 일할 때 초당 6000 개 이상의 syslog 메시지를 처리하는 로깅 버스에서 작업 중이 었으며 패킷 손실 및 손상을 측정해야했습니다. 거의 모든 구성 요소, 특히 Syslog 파서에 대한 단위 및 스트레스 테스트를 작성했습니다.

개발자가 단위 테스트를보다 쉽게 ​​수행 할 수 있도록

나는 그들이 강제로해야한다고 생각합니다. 현명한 고객이라면 컨설턴트가 모든 QA에서 전체 테스트 스위트를 실행해야합니다. 훌륭한 팀 리더라면 다음과 같은 작업을 스마트 개발자에게 할당하는 것이 좋습니다. 내부 테스트 플랫폼을 구축하십시오. 내부 효과 플랫폼 antipatter로는 볼 수 없지만 개발자 클래스가 즉시 테스트를 빌드하는 데 도움이되는 도우미 클래스, 데이터베이스 모의, 구성, 파서, 변환기, 스위스 군용 나이프 세트입니다.

NUnit과 같은 현재 테스트 플랫폼은 범용이며 일반 어설 션을 확인할 수 있습니다. 종속성 주입과 프로젝트 별 팩토리를 올바르게 사용하면 개발자가 테스트를위한 코드를 적게 작성하고 더 행복해집니다. 아직 전체 프로젝트에서이를 실험 할 기회가 없었으며 실제 피드백을 제공 할 수 없습니다.

자동화 된 테스트는 소프트웨어 개발과 같습니다. 불행히도 테스트를 위해 고용 한 사람들은 원래 테스트 사례, 계획, 전략을 작성하고 검토 프로세스를 따르고 버그를 수동으로 테스트하고 기록합니다.

자동화 된 테스트 책임이 부여 되 자마자 약간의 소프트웨어 개발이 포함됩니다. 여기서 중요한 것은 자동화 된 테스트는 사용하는 도구에 관계없이 (그리고 하늘을 위해이 시점을 주장하지는 않음) 매일 유지 보수 및 업데이트가 필요하다는 것입니다. 개발자가 코드를 변경함에 따라

• 테스트가 계속 실행되고 있는지 확인해야합니다.
• 테스트가 실행되지 않았으므로 테스트가 제거되지 않았는지 확인해야합니다.
• 테스트 메트릭에는 마지막 빌드 및이 빌드에서 실행 한 내용이 표시되어야합니다. 테스트 사례 수가 줄어들지 않도록합니다.
• 테스트 사례는 사람들이 엉망이되지 않도록 개발과 같이 검토해야합니다. 일부 테스트를 2로 나누면 숫자가 증가합니다 (때로는 테스트가 아웃소싱 되므로이 추적이 중요합니다)
• 개발자와 테스트 사이의 훨씬 더 "건강한"의사 소통이 중요합니다
• non-functional테스트를 개별적으로 유지 하고 매일 테스트를 수행 할 것으로 예상하지 않으면 테스트를 최신 상태로 유지하는 데 시간이 걸립니다. 그러나 포기하지 말고 유지하십시오.

이러한 이유로 인해 실패

• 테스트 엔지니어는 분석 기술이없는 수동 테스트 엔지니어입니다. 그들은 a if와 while루프 의 차이점을 모릅니다 . 솔직하게는 자동 테스트를 가르치는 과정이 없기 때문에 수동 테스트 만 가르칩니다.
• 테스트 엔지니어는 빌드를 수동으로 테스트하고 버그를 로깅하여 자동화 된 테스트를 추적하기에 너무 바쁩니다.
• 테스트 관리자는 프로젝트가 시작될 때 유효하지 않은 데이터를 표시하기 때문에 자동화 된 테스트의 메트릭을 신경 쓰지 않으며 자동화 및 실행을 얻는 것이 얼마나 중요한지 강조하기 위해 매일 스탠드 업 및 회의에서 노력이나 우선 순위를 두지 않습니다.
• 유효 기간이 매우 짧은 모바일 애플리케이션에 대한 테스트를 자동화하도록 선택합니다. 작성할 때까지 자동화 된 테스트 스위트의 애플리케이션 요구 사항이 변경되는 대신 애플리케이션을 실행하는 웹 서비스 테스트에 집중해야합니다.
• 자동화 된 테스트 팀이 개발 팀, 기능 완료, 코드 완료, 코드 잠금 및 코드 동결과 같은 이정표를 따른다는 것을 이해하지 못합니다.
• 수동 테스트 사람들과 자동 테스트 사람들을 구별하지 마십시오.
• 둘 다 동일한 급여를 받고 동일한 관리자에게보고합니다. 이상적으로는 개발자 관리자에게보고해야하며 급여는 개발 급여와 일치해야합니다.
• 당신은 실제로 junit이 자동 테스트를 개발하기에 충분하지 않다고 생각하고 믿습니다. :).

자동화 테스트를 매우 진지하게 받아들이고 개발자가 자동화 테스트 엔지니어로서 중요하다는 것을 이해 한 회사에서 일한 경험이 있습니다. 그리고 내가 모르는 사람들을 위해 일한 나의 경험에서, 당신이 그들에게 아무리 설명해도 차이를 이해하십시오.