팀의 새로운 사람이면서 기존 통합 및 단위 테스트의 품질에 대해 무엇을 할 수 있습니까?

내 경력에서 반복되는 주제는 새로운 개발자가 팀에 합류하고 기존 장치 및 통합 테스트 스위트에 대한 내재 된 불신을 빠르게하는 것입니다.

인터뷰 중에 경영진은 "단위 테스트를 강력하게 지원"하고 공개적으로 장려한다고 말합니다. 그들은하지만 테스트 자체에 대한 모든 것은 명백한 잘못입니다. 통합 테스트 범위는 100 %이지만 반복 가능한 단위 테스트 범위는 10 % 미만일 때 100 % 범위를 차지한다는 사실과 같습니다. 내가 찾은 다른 문제들 :

1. 단위 테스트와 통합 테스트는 명확하지 않습니다. 단위 및 통합 테스트는 동일한 클래스에서 함께 혼합됩니다.

2. 특정 환경 데이터베이스의 매우 구체적인 동적 데이터에 대한 명시 적 종속성이없는 통합 테스트

3. 비 트랜잭션 통합 테스트, 기본적으로 자체 정리 후 귀찮게하거나하지 않을 수있는 테스트, 때로는 테스트를 반복 가능하게하기 위해 수동 데이터베이스 "스크러빙"이 필요합니다.

4. 조롱 할 필요가 없으며, 응용 프로그램 코드는 조롱이 가능하도록 대대적 인 점검이 필요합니다. 다시 말해, 테스트를 염두에두고 디자인하지 마십시오.

5. 테스트 이름을 빠르게보고 어떤 테스트가 수행되는지 대략적으로 결정하는 명확한 명명 규칙이 없습니다.

이것은 모든 테스트가 쓸모 없거나 나쁘다는 것을 의미하지는 않습니다. 많은 테스트가 꽤 좋고 유지 가치가 있지만 때로는 금을 패닝하는 것처럼 느껴집니다. 블랙 박스 테스트 사례를 위해 데이터베이스를 망쳐 놓는 것을 두려워했기 때문에 테스트를 의도적으로 피하는 것이 좋습니다.

이것은 본질적으로 개인적으로 작성하거나 검토하지 않은 단위 및 통합 테스트에 대한 고유의 불신 을 주었다 . 어떤 수준에서 테스트 스위트의 품질에 대한 믿음이 없다면 팀이나 프로젝트에 아무런 가치가 없습니다.

이 상황에서 자신을 찾으면 어떻게해야합니까? 가장 좋은 공격 계획은 이와 같은 것을 다루는 것이라고 생각합니까?

릴리스 전체에 걸쳐 엄청난 노력으로 모든 테스트를 리팩터링해야합니까? 이 레거시 프로젝트에 하루 단위의 견고한 단위 테스트 적용 범위가 있다는 아이디어를 포기해야합니까?

우선, 다른 포스터가 이미 썼 듯이, 당신은 단위 / 통합 테스트가 (기술적 인 방식이 아니라 그것이 수행되어야하는 이유를 이해한다는 것을 의미 함) 이해되고 경영진에 의해 추진되는 것을 기뻐해야합니다.

모든 일을 시작하기 전에 경영진에게 문제를 제기해야하는 이유, 무엇을해야하는지, 그리고 외교적으로 자신이 세상에서 가장 훌륭한 프로그래머라고 생각하지 않도록 매우 외교적으로 표현해야합니다. 어쩌면 그들은 응용 프로그램이 완전히 새로운 것으로 대체 될 것이라고 말할 것입니다. 그렇다면 왜 귀찮게합니까? 어쩌면 그들은 매번 릴리스하기 전에 그것이 좋을 것이고 테스트 단계를 가속화 할 것임을 알 것입니다. 그리고 팀원들과 외교를해야합니다. 그 이유는 백만 가지 일 수 있으며, 범인을 찾아야 할 이유는 없습니다.

더 나은 아이디어는 그들이 노력에 참여할 수 있도록 그들과 대화를 시도하는 것이며, 당신은 현명한 엉덩이처럼 보일 가능성이 적습니다. 그것은 "나"보다 "우리"일 것입니다.

이제하고 싶은 일에 우선 순위를 두십시오. 작업의 우선 순위를 정하고 항상 첫 번째 우선 순위가 항상 현재 프로젝트 할당임을 알고 있어야합니다 ... 테스트 문제는 다음 3 단계로 수행 할 작업입니다.

1. 단위 테스트와 통합 테스트를 차별화하는 방법은 무엇입니까? 다음과 같은 솔루션이 적용되며 배타적이지 않습니다.

   • 테스트 케이스 메소드의 이름을 리팩터링하십시오 (올바른 동작은 테스트 케이스가 테스트 된 클래스와 동일한 이름을 공유하도록하기 때문에 클래스가 아님).
   • 하나는 "UnitTest", 다른 하나는 "IntegrationTest"라는 두 개의 주석을 작성하십시오. 이러한 주석은 클래스와 메소드에서 사용할 수 있습니다. 전체 클래스가 단위 또는 통합 테스트로 구성된 경우 올바른 주석으로 클래스를 표시 할 수 있습니다. 그렇지 않은 경우 올바른 주석으로 각 방법을 표시 할 수 있습니다. 또한 이러한 주석은 테스트를 시작하기 전에 조명기를 동적으로 주입하는 데 유용 할 수 있습니다 (단계 3).

2. 각 통합 테스트에 대해 각 테스트 시작시 데이터베이스에있을 것으로 예상되는 "데이터 세트"란 무엇이며, 테스트 종료시 제거해야하는 항목 (예 : 표 X, "id"가있는 레코드가 필요함)을 나열하십시오. "1"로 설정하고 "name"을 "foo"로 설정) 코드 자체가 지속성 레이어에서 객체를 각각 추가 / 제거 할 수 있으므로 제거하는 것이 처음에 가지고있는 것보다 더 크거나 작을 수 있습니다. 이러한 테스트 사례 중 일부는 동일한 데이터 세트 또는 동일한 데이터 세트의 일부가 필요하다는 것을 가장 빨리 알 것입니다.

3. 처음 두 단계는 나머지 단계에 비해 비교적 빠르게 수행 할 수 있습니다. 이제 데이터 세트가 준비되었으므로 필요한 각 테스트 케이스에 대해 데이터 세트 작성 도구를 사용하십시오. 하지만 시간이 좀 걸릴 것입니다 ... 그래서 당신은 한 번 할 수 있고, 시간이 얼마나 걸리는지, 모든 일을 얼마나 더해야하는지 추정 할 수 있습니다. 또한이 테스트를 사용하여 동료 동료에게 수행 한 작업과 테스트를 수행하기 위해 특정 주 쥬트에 데이터베이스가 필요하지 않은 경우 인생이 훨씬 더 쉬운 이유를 보여줄 수 있습니다.

동료 / 관리자에게 수행 방법을 신속하게 보여주고 싶다면 1, 2, 3 단계를 단일 테스트 클래스에서 수행 할 수 있습니다. Péter Török이 작성한 것처럼 이는 팀원에게 나쁜 코드 생성을 중지하도록 "좋은 방법"을 즉시 보여주기 위해 유용 할 것입니다. 그러나 전체 테스트 데이터 세트를 식별하는 나머지 2 단계는 하나의 큰 단계로 수행하는 것이 가장 좋습니다.

API / 기술의 모든 측면에서 주제를 아는 것 같습니다.

그것이 약간 도움이 되었기를 바랍니다.

참고 : 내 제안에 대해서는 주석을 알고 AOP가 가능한 Java / C #으로 코드를 작성한다고 가정합니다. 나는 이것이 다른 언어로도 가능하다고 확신하지만, 내가 모르는 것에 대해서는 쓰지 않을 것입니다.

모든 테스트를 함께 고칠 수는 없습니다. 나는 당신이 개선 대 정비 에 중점을 두어야한다고 생각합니다 . 경영진 모두 개발자가 점검에 동의하지는 않지만 프로젝트에 부정적인 영향을 미치지 않으면 서 개선 할 수있는 방법이 있음을 보여 주면 더 잘들을 수 있습니다.

첫째, 품질 테스트 범위가 없으면 기존 코드를 '수정'하거나 리팩터링 할 수 없으므로 테스트 인프라를 먼저 수정하는 데 중점을 둡니다.

개선이 필요한 것들의 목록을 만들고 우선 순위를 정하십시오. 테스트를 독립적으로 또는 단독으로 실행할 수있는 능력 (서로 다른 영향을 미치지 않음)과 단위 및 통합 테스트의 분리가 가장 먼저해야 할 일이라고 생각합니다. 자신과 다른 사람이 올바른 일을 쉽게 할 수 있도록해야합니다.

응용 프로그램 코드에 관한 한 ... 응용 프로그램 아키텍처를 완전히 점검하여 더 나은 단위 테스트를 수행 할 수는 없습니다. 대신 새 코드를 입력 할 때 종속성 테스트와 같이 단위 테스트를보다 쉽게 ​​수행 할 수있는 원칙을 적용하십시오. 이것이 충분히 큰 변화는 아니라고 생각할 수도 있지만, 개발자가 이점을 볼 때 얼마나 빨리 따라 잡는지는 놀라운 일입니다. 더 나은 변화를 시작하는 사람이 필요합니다.

팀과 대화하고 구매를 유도하십시오. 당신이 할 수있는 가장 중요한 것 중 하나는 ' 보이 스카우트 규칙 (Boy Scout Rule) '을 따르고 수업이나 시험을 좀 더 나은 상태로 만들기 위해 약간의 개선을 한 것 입니다. 팀 전체가이 규칙을 적용하면 상황이 훨씬 빨라집니다.

잠시 후, 응용 프로그램의 좋은 원칙과 영역을 따르지 않는 많은 코드가 생깁니다. 이 시점에서, 당신은 좋은 것이 무엇인지에 대한 기준을 가지고 있으며, 팀은 오래된 레거시 물건에 대해 더 큰 리팩터링을 수행하는 것이 유리한지 또는 그대로 유지할 수 있는지 결정할 수 있습니다.

나는 그들이 이미 상당한 수의 단위 / 통합 테스트를 가지고있는 프로젝트에 도착하기 위해 희귀 한 선물로 받아 들일 것이라는 점을 인정해야한다. 모든 직원이 원하는대로 작동하지 않더라도 이미 많은 노력을 기울이고 있으며 팀과 경영진이 항상 모범 사례를 따르지 않아도 여전히 원인에 헌신하고 있습니다. 단위 테스트가 왜 가치가 있는지에 대해 논쟁하는 데 시간을 소비하지 않아도됩니다.

그러나 설명하는 테스트는 실제로 약간의 개선이 필요할 수 있습니다. 그러나 팀원들과 문제를 논의 할 때는주의를 기울여야합니다 . 당신이 진술에 의해 시작하면 "테스트에 대한 모든 것을 자신이 그냥 일반 잘못이다" , 당신은 매우 빠르게 팀의 나머지 부분을 소외 끝낼 수 있습니다. 대신 현재 상황을 개선하는 방법에 중점을 두어야합니다. 지금까지의 경험에 따르면, 반복해야합니다. 여전히 평균보다 훨씬 낫습니다.

IMO 의 첫 번째 목표는 팀이 더 나쁜 테스트를하지 못하게하는 것 입니다. 따라서 팀원에게 각 특정 개선의 이점을 보여주는 것으로 시작하십시오. 외부 종속성을 절단하거나 각 테스트 후 원래 상태를 복원하거나 단위 및 통합 테스트를 분리하는 등 특정 기술의 유용성을 발견하면 적용을 시작합니다. 이것만으로도 장기적으로 테스트베이스의 전반적인 품질이 느리지 만 확실하게 향상 될 것입니다 (지금 1000 개의 나쁜 테스트 사례가 있고 내년까지 1000 개의 좋은 테스트를 생성하는 경우 나쁜 테스트의 비율을 낮추게됩니다) 100 %에서 50 % 사이). 일단 확보되면 기존 테스트를 사례별로 리팩토링할지 결정할 수 있습니다. 다시 한번, 약간의 개선은 시간이 지남에 따라 큰 변화를 가져옵니다.

부수적으로, 당신의 게시물의 분위기에서 나는 당신이 너무 예전의 장소에 있다고 생각합니다. 자체 품질 표준. 내 경험상, 이것은 장기적으로는 개인적인 갈등과 소진으로 이어질 수 있기 때문에 좋은 장소가 아닙니다. 모든 것을 혼자서 할 수는 없으며 나머지 팀과 협력해야합니다. 당신은 함께 성공할 수 있습니다.

시험 독립을 향해 노력하십시오. 테스트 X가 테스트 Y가 실패하는 방식으로 테스트 데이터베이스를 수정하는 경우 테스트 Y를 변경하십시오.이 작은 시나리오에서 중점을 두어야 할 것은 X가 데이터베이스를 엉망으로 만든 것이 아니라 Y가 부적절한 종속성을 가지고 있다는 것입니다. 데이터베이스를 스텁 아웃하거나 테스트를 재구성하거나 데이터베이스를 Y가 통과하는 상태로 초기화하여 이러한 종속성을 제거하면 이제 독립적이고 작동하는 테스트가 하나 더 있습니다. 그것은 진전입니다 (아마도, "고정"X는 데이터베이스를 망쳐 놓지 않을 것입니다).

그들이 만든 혼란에도 불구하고, 당신과 함께 일하는 사람들에 대해 가능한 한 인내심과 존 중심을 가지십시오. 그들은 옳은 일을하려고 노력하고 있습니다. 그 점을 명심하고 그렇게하도록 도와주십시오.

팀에 새로 온 것에 대한 좋은 점은 사물에 "신선한"접근 방식이 있다는 것입니다. 나쁜 부분은 다른 사람들이 당신을 믿기가 힘들 수 있다는 것입니다.

세탁물 목록을 작성하지 마십시오. 그러나 시급 해 보이고 다른 사람들이 가장 잘 반응하고 해결책을 제시 할 수있는 것을 하나 선택하십시오. 그것이 효과가 있다면, 첫 번째 성공의 힘에 대해 다른 문제에 대한 다른 해결책을 제안하십시오.

그러나 하나씩 느리게 생각하고 새로운 그룹 사이에서 아이디어가 느리게 "포획"되기를 바랍니다.

보고자하는 예제를 설정하되 테스트에서 다른 개발자의 관점을 이해하십시오. 한 개발자는 성공을 테스트 할 수 있고 다른 개발자는 실패를 테스트 할 수 있으며 한 개발자가 클래스를 작성하고 다른 개발자가 테스트를 작성할 때 처음으로 클래스를 사용했을 수 있습니다.

기존 테스트 (erm, most)는 여전히 분명하지는 않지만 여전히 목적이 있습니다. 모든 것을 한 번에 점검하고 리팩토링하지 않는 것이 좋습니다 (지루하고 오류가 발생하기 쉽습니다). 나쁜 테스트는 궁극적으로 업데이트, 재 작성이 필요하거나 소프트웨어가 발전함에 따라 단순히 폐기 될 수 있습니다.

테스트에 대한 접근 방식이 어떤면에서 우수하면 사람들은 해당 모델에서 배우거나 도움을 요청할 것입니다. 균형 잡힌 자원이 있지만 테스트 지원에 필요한만큼 확장 할 수 있습니다.

궁극적으로 테스트를 통해 프로그램의 품질을 높이고 적용 범위를 향상 시키려고합니다. 당신은 테스트와 좋은 모범을 세우는 것에 더 중점을 두어 이것을 할 수 있지만 다른 관점에 대해서는 감사합니다.

중요성을 강조 할 때 테스트 운영 환경을 다르게 만들 수 있습니다. 명백한 예는 테스트를 병렬로 실행하는 것입니다. 재진입하지 않으면 프로그램이나 테스트 (win / win)에 버그가있는 것입니다. 보다 엄격한 테스트 환경은 잘못된 테스트를 수정 및 / 또는 다시 작성하도록합니다 (두 번째로 올바른 방법). 그러한 변화를 천천히 도입하십시오 (한 번에 절반의 테스트를 중단하지 마십시오. 실제 문제입니다). 좋은 테스트와 궁극적으로 좋은 프로그램을 배우도록 강요하십시오. 그런 다음 당신과 다른 사람들이 들어 와서 테스트를 수정 / 수리 / 확장 할 때, 배운 것을 적용하십시오-그것은 점진적이며 당시의 상황 / 프로그램에 대해 더 잘 이해하고 있습니다.

시간이 지남에 따라 수정

나는 같은 상황에 있었다. 나는 매일 아침 한 시간 동안 테스트를 거쳐 테스트가 끝날 때까지 수정했습니다. 중간 크기의 코드베이스 였고 1.5 개월 만에 끝났다고 생각합니다. 나는 또한 우리의 테스트에 훨씬 더 자신감을 얻었다.

테스트가 좋은 테스트라면 단위 테스트인지 통합 테스트인지는 개인적으로 상관하지 않습니다. 좋은 시험으로 나는 그것을 의미합니다 :

• 자체 청소
• 반복 가능하다
• 환경 상호 작용을 최소화
• 일관성이있다

그 과정에서 나는 더 나은 테스트 구성을 복음화했다 (즉, 사람들을 많이 괴롭혔다).