단위 테스트 전후에 코드 검토를 수행해야합니다

단위 테스트 전후에 코드 검토를 수행 할시기에 대해 동료와 논의 중입니다. 모범 사례는 무엇입니까?

우리가 고려해야 할 몇 가지 요소가 더있을 수 있습니다.

• 코드 변경 크기-큰 변경은 코드 검토에서 더 많은 변경이 발생 함을 의미합니다. 이러한 변경 사항이 UT보다 코드 검토 이전 인 경우보다 더 큰 경우 대부분의 UT를 다시 반복해야합니다.
• 단위 테스트를 수행하는 데 필요한 시간
• 새로운 기능입니까, 버그 수정입니까?

코드 검토 를 수행 하기 전에 항상 단위 테스트 를 수행 해야하며 그 이유는 다음과 같습니다.

1. 코드가 단위 테스트에 걸리는 방식으로 손상되면 다른 개발자가 빨강 / 녹색 / 리 팩터주기에 참여하게함으로써 다른 개발자의 시간을 낭비하게됩니다.
2. 테스트를 통해 다른 개발자가 코드를 쉽게 사용할 수 있으므로 검토하기가 더 쉽습니다.
3. 테스트 사례가 누락되었거나 테스트가 제대로 작동하지 않는 경우 테스트 된 코드와 함께 테스트를 검토해야합니다.
4. 테스트와 코드 검토는 발견 된 문제가 약간 겹치면서 다른 문제를 포착하는 경향이 있습니다. 리뷰어가 문제를 발견하면 개발자가 코드를 다시 테스트해야 할 때 단위 테스트가 성가 시게되지 않으며 개발자는 성가 시게되고 아마 두 번째로는 잘하지 않을 것입니다.

아마도 다른 이유가있을 수 있지만 이것이 제가 개인적으로보고 경험 한 세 가지 팀 / 회사 내에서 코드 검토 관행을 구현 한 이유입니다.

편집 위의 내용은 코드 검토가 소프트웨어 개발 프로세스 (폭포 또는 민첩성)의 한 단계 인 경우를위한 것입니다. 특히 크거나 어려운 코드 섹션에서 작업하는 경우 언제든지 다른 코드 쌍을 주시하십시오.

코드 검토는 코드가 "완료"된 경우입니다.

조직에서 "완료"에 대한 정의에는 단위 테스트 (TDD를 목표로 함)가 포함되므로 코드 검토는 완전한 코드이며 완전한 코드에는 테스트가 포함됩니다.

또한 테스트는 검토 및 리팩토링이 필요하므로 코드 검토의 일부라는 의미가 있습니다.

테스트는 코드의 일부로 검토해야합니다. 따라서 테스트가 완료된 후 검토하는 것이 좋습니다.

테스트도 검토해야합니다. 이것은 단위 테스트를 처음 접하는 사람들에게 중요합니다.

팀이 의존성 주입, 격리 프레임 워크, 모의 대 스텁, 이음새, 상호 작용 대 상태 기반 테스트 및 통합 대 단위 테스트를 이해하도록하십시오.

위에서 언급 한 주제를 구현할 필요는 없지만 이해해야합니다.

잘,

이것은 "단위 테스트"의 의미에 따라 다릅니다.

TDD 스타일 단위 테스트 인 경우 코드를 작성하는 동안 테스트를 작성하므로 의미가 없습니다. 이후의 사례는 없습니다.이 경우 코드 품질을 지속적으로 향상시킵니다. 리팩토링 ...

과

그것이 고전적인 "단위 테스트"였다 [알지 못한다는 것을 의미하지만, 코드를 작성하고 일반적으로 다른 사람들이 수행 한 후에 테스트를 의미한다]라면, 주요 기준은 코드 검토 및 단위 테스트의 특성에서 기대하는 것입니다. 빠른 피드백을 원하고 검토하고 조치를 취하며 자동화 된 단위 테스트가없는 경우 단위 테스트를 기다려야합니다. 코드 검토와 관련하여 성숙한 문제를 식별하고 다음 반복에 대해 점진적으로 솔루션을 적용하려면 단위 테스트 전에 수행 할 수 있습니다.

그러나 결국 개인적으로, 코드 검토를 위해 나중에 단위 테스트가 나에게 진정한 기준이 아닙니다 ...

왜 우리가 코드 검토를합니까? 코드 품질 ... "품질 관리"게이트 대신 소프트웨어 개발 프로세스 환경에 품질을 주입하십시오.

나는 "민첩하다"고 말하려는 경향이 있습니다 ... 코드를 완성하기 위해 코드를 완성하기를 기다리지 말고 비공식적 인 코드를 검토하십시오. 코드 + 테스트 단계 완료 ... 하지만

정말 새로운 주제 (새로운 기능, 거의 모든 연구, 팀에 완전히 새로운 것)에 관해서는, 코드 검토를 일찍, 느슨하게하지 마십시오. 이 경우 실패의.

개발자가 팀에 익숙하지 않은 경우 코드를 조기에 검토하고 자주 검토하십시오 .

그건 그렇고, 단위 테스트뿐만 아니라 코드 검토가 필요합니다.