단위 테스트 초보자 팀은 단위 테스트가 필요합니다

나는 역사적으로 어떤 단위 테스트를 수행하지 않은 새로운 팀과 함께 일하고 있습니다. 내 목표는에 팀이다 결국 자신의 자연적인 과정으로 고용의 TDD (테스트 개발을 주도). 그러나 TDD는 비 단위 테스트 팀에게는 근본적인 마음 전환이므로 코딩 후 단위 테스트 작성부터 시작하겠다고 생각했습니다.

비슷한 상황에 처한 사람이 있습니까? 팀이 단위 테스트를 수행하지 않았을 때 TDD에 익숙해 지도록하는 효과적인 방법은 무엇입니까? 몇 가지 단계로이 작업을 수행하는 것이 합리적입니까? 아니면 우리가 바로 뛰어 들어가면서 점점 커지는 모든 고통에 직면해야 하는가 ??

편집하다

설명을 위해 팀에 노출 / 경험을 테스트하는 단위를 가진 사람은 없습니다. 그리고 Visual Studio에 내장 된 단위 테스트 기능을 사용할 계획입니다.

기존 버그 / 결함에 대해 연습하십시오.

이것은 정말 힘든 상황입니다. 나는 결코 전에 아무것도 TDD에 가본 적이 없지만, 내 경험상, 팀이 단위 테스트를하지 않고 적극적으로 작성하는 것은 한 번에 한 단계 씩 접근하는 것이 었습니다.

첫째, 편한 단위 테스트를 작성하고 자신이 무엇인지 그리고 그들의 이점을 실제로 알도록하십시오. 우리 팀의 경우 기존 버그에 대한 단위 테스트를 작성하는 것이 가장 좋습니다. 시스템의 현재 버그에는 사람들에게 단위 테스트를 잘 작성하도록 가르치는 데 필요한 두 가지 사항이 있습니다.

1. 예상되는 전제 조건과 사후 조건
2. 현재 예상치 못한 결과와 그 전제 조건 / 사후 조건을 위반하는 결과

이것은 회원들에게 매우 구체적인 연습 사례를 제공합니다. 버그를 수정하기 전에 테스트를 작성하여 실패 할 수 있습니다. 그런 다음 코드를 수정하여 전달하고 버그를 수정할 수 있습니다. 일단 이것에 익숙해지면 코드를 미리 보지 않고 단위 테스트를 작성한 다음 새 코드를 작성하여 테스트를 통과 할 수 있도록 나머지 방법을 사용할 수 있습니다.

트릭은 그들에게 명확한 방법 사전 / 사후 조건이있는 곳에서 연습 할 무언가를주는 것이라고 생각합니다. 분석법에 대한 요구 사항이 모호한 경우 숙련 된 TDD 직원조차도 정확히 어디에서 시작해야하는지 알기가 어렵습니다. 한 번에 한 걸음 더 나아가십시오. 행운을 빕니다!

회사 전체가 TDD로 전환하도록 설득했습니다. 쉽지는 않았지만 노력할만한 가치가있었습니다. 코드 품질이 전환 후 올라 갔으며 이제는 끔찍한 카우보이 코딩 시대로 돌아가는 사람은 아무도 없습니다.

1. 설명하고 설명하고 설명하십시오. 당신은 당신의 팀이 테스트를 작성하기를 원하지 않습니다. 팀이 테스트를 작성 하기를 원합니다 . 즉, 왜 해야하는지, 어떤 이점이 있으며, 이것이 어떻게 업무를 훨씬 쉽게 할 수 있는지 완전히 이해해야 합니다. Red, Green, Refactor , 버그 수정 등의 증거로 회귀 테스트 작성 등 모든 코드 작성을 요청하기 전에 모든 것이 이해가되는지 확인해야합니다.

2. 진짜로 가십시오 (먼저 테스트 한 다음 코드). 실제로 작동하는지 여부를 알 수 없으므로 사람들은 버그가있는 테스트 사례를 작성하므로 코드 다음에 테스트를 작성하는 것은 의미가 없습니다. 나의 직관은 당신이에서 갈 필요가 노력의 양이다 어떤 시험 에 시험이 처음 훨씬 적은 당신이 형성되지 갈 필요가 무엇보다 더 테스트 를 통해 첫 번째 코드를 에 첫번째 테스트 당신은뿐만 아니라 중간 단계를 건너 뛸 수 있도록.

3. 회귀 테스트로 시작하십시오. 이것들은 이해하기 매우 간단하며 즉각적인 만족감을줍니다. 물론 이것은 코드가 올바르게 모듈화되어 있고 쉽게 테스트 할 수 있다고 가정합니다. 그렇지 않은 경우이 단계를 건너 뛰십시오.

4. 아기 발걸음을 내 딛으십시오. TDD는 익숙해지는 데 시간이 걸리고 처음에는 실망 스러울 수 있습니다. 아주 새로운 프로젝트 나 구성 요소에 테스트를 도입 해보십시오. 정말 빠르게해야 할 중요한 일이 있고 프로그래머가 TDD가 방해하고 있다고 느끼는 상황을 피하려고합니다.

5. 팀이 편해지기 시작하면 모든 새로운 기능을 TDD 방식으로 작성하십시오. 이것은 프로젝트의 규모에 따라 다르지만, 얼마 후에 는 오래된 방식으로 작성된 일부 레거시 부분 만 포함하여 꽤 좋은 범위를 확보해야합니다 .

6. 이 시점까지 팀은 이미 TDD를 이해하고 수용해야하며 레거시 (비 TDD) 항목은 작업하기 어렵고 성가신 것으로 간주되어야합니다. 그것을 리팩토링하십시오 : 대부분의 포플은 기쁨으로 그것을 할 것입니다.

다른 중요한 사항들 :

• 사용 가능한 최상의 테스트 프레임 워크를 사용하고 있는지 확인하십시오. 사람들이 잘못 작성된 라이브러리와 상호 작용해야하는 경우 사람들이 TDD를하도록 설득하는 것이 훨씬 더 어려울 것입니다.

• 테스트를 쉽게 실행할 수 있고 완료하는 데 많은 시간이 걸리지 않도록하십시오 (또는 테스트에 인 메모리 DB를 사용하여 속임수를 쓰십시오).

• 끊긴 테스트가 즉시 발견되도록 일부 지속적인 통합 소프트웨어를 설정하십시오.

TDD에 익숙해지는 한 가지 방법은 먼저 통합 테스트를 작성하는 것입니다. 나중에 테스트 솔기 및 실제 단위 테스트를 소개합니다.

코딩 후 단위 테스트 작성의 문제점은 코드 가 테스트 가능하도록 잘 설계되지 않았을 수 있다는 것 입니다. 테스트 이음새를 도입하기 위해 리팩토링을 수행하거나 재 설계해야 할 수도 있습니다. 그러나 어떤 종류의 테스트 범위가 없다면 어떻게 안전하게 리팩토링하거나 다시 설계 할 수 있습니까?

통합 테스트는 처음에 해당 범위를 제공 할 수 있습니다. 회귀 또는 생산 문제가 발생할 때마다 코드에서 문제를 해결하고 테스트로 해당 코드를 커버하십시오. 이러한 테스트를 통해 충분한 안전망을 확보 한 후에는보다 세밀한 격리 된 구성 요소 및 / 또는 시스템 클래스의 단위 테스트를 도입 할 수 있습니다.

TDD는 구현하기가 매우 어렵고 모든 개발 팀에 항상 최상의 옵션은 아닙니다. 저의 이전 업무에서 팀은 TDD에 크게 집중했습니다. 우리의 개발 모델은 민첩한 개발 방식을 사용하는 TDD였으며 테스트는 Visual Studio 단위 테스트를 통해 수행되었습니다.

개발자가 자신의 기능에 대한 단위 테스트를 작성하지 않은 경우 기술 리드에 문제가있을 수 있습니다. 또한 누군가가 깨진 빌드 또는 단위 테스트를 체크인하는 경우 개발자는 모든 문제를 해결하고 팀 돈 항아리에 1 달러를 추가해야합니다.

추가 할 작은 것만으로 프로세스를 시각화하십시오. 지속적인 통합 실행 테스트를 자동으로 수행하고 코드 적용 범위를 확인하십시오. 모든 사람이 볼 수있는 가장 완벽한 테스트 모듈을 시작 페이지에 나열하십시오. 팀 경쟁이 진행될 것입니다.

나는 JUnit 경험이 없었기 때문에 TDD로 갔으며, 그 경험으로 TDD의 가치가 명백하게 드러났습니다. 나는 단위 테스트에 너무 감사하여 접근 방식의 전도자가되었습니다.

나는 단위 테스트를 수행하지 않은 팀을 방문했지만 소개되었지만 거의 일부 테스트를 수행하는 것이 일반적이되었습니다. 팀이 단위 테스트의 기본 사항을 이해하고 여기에 어떤 도구를 가져오고 싶습니까?

필자의 경우 비즈니스 로직, 사용자 인터페이스 및 백엔드 기능이 혼합 된 일부 .Net 코드에 대해 nUnit을 가져 왔습니다. 나는 팀원 중 일부가 그것을 얻을 수 있도록 다른 사람들보다 더 기꺼이하고 싶어하는 사람들이 있는지 확인하고 당신이 모든 사람을 얻으려고 노력하는 플립 쪽보다 조금 더 잘 퍼질 수 있음을 제안합니다. 이것에 뛰어 들기 위해. 일부는 먼저 잘 수행함으로써 일부 교차 훈련을 가능하게하여이를 수집 한 사람이 다른 사람에게 얼마나 잘 가르 칠 수 있는지 테스트 할 수 있습니다.

또 다른 요점은 이것을 어느 정도 보여줄 수있는 더 많은 전문 지식을 가진 사람들을 데려 오는 것을 고려하는 것입니다. Thoughtworks는 내가 우리에게 그 부분 중 일부가 널리 채택되고 다른 부분은 그다지 많지 않은 것을 보여주기 위해 일하게되었지만, 대부분의 장소에서 이것이 사실이라고 생각합니다.