내 동료가 내가 흥미로웠다는 아이디어를 생각해 냈습니다.

코드를 검토하는 동안 TDD를하지 않는다고 가정하여 코드를 검토하는 동안 테스트를 작성하는 것이 유리하지 않습니까?

이 질문에 대해서는 이것이 순수한 학업 프로젝트라고 가정하므로 생명이 위태로워지지 않습니다. 또한 팀은 4 명입니다. 누구나 언어를 알고 사용 된 모든 도구 / 라이브러리 / 프레임 워크에 익숙하며 테스트를 작성할 수 있습니다. 기본적으로 선임 풀 스택이 아닌 사람들은 닌자 엔지니어가 아니라 괜찮은 코더를 이끌고 있습니다.

내가 찾은 장점 :

1. 의미있는 테스트를 작성하기 위해 검토하는 동안 코드를 더 깊이 이해하도록 장려합니다.
2. 그런 다음 테스트중인 코드 작성자가 수행 한 테스트에 대한 코드 검토를 추가 할 수 있습니다.

내가 찾은 단점 :

1. 코드 작성과 테스트 사이의 피드백 루프가 커집니다.

편집 : "정상적인"웹 응용 프로그램에서 제대로 작동하지 않는다는 것을 알고 있습니다. 내가 염두에 둔 것은 세부 사항에주의를 기울여야하는 복잡한 과학 알고리즘을 구현하는 코너 케이스였습니다. 우리 자신의 그래프 라이브러리, NLP 등을 구현하는 것과 같은 것을 가정 해 봅시다. 우리가 작성하는 코드가 데이터베이스와 분리되어 있는지 이해하기는 어렵지만 소스를 이해해야하는 다른 사람은 추가 제어 수준을 이해하지 못할 것입니다. 코드를 작성하고 의미있는 테스트를 수행하면 전체 프로세스가 응용 프로그램을 중단 시키지는 않지만 결과가 엉망이되는 덜 명백한 버그에 덜 취약합니까?

코드 검토 중에 검토를 수행하는 사람이 테스트를 작성하는 것이 유리하지 않습니까?

테스트를 작성하기에 좋은시기는 상황에 대한 테스트가 필요하다는 것을 알았습니다.

컴퓨터의 작업 전환은 비용이 많이 들고 사람에게는 훨씬 비쌉니다.

이 시점에서 일반적으로 테스트의 요구 사항과 종속성을 잘 이해하고 있습니다. 따라서 문제에 팀의 몰입을 활용하십시오. 미래에 새로운 테스트를 개선해야 할 경우 이미 테스트 프레임 워크 / 픽스처가 준비되어 있으며 개선이 필요한 부분을 변경하기 만하면됩니다.

코드 검토 중에 이런 일이 발생하면 어떻게해야합니까? 전에 해봤어요 나는 그것이 당신이 빨리 할 수 ​​있다면, 그렇지 않으면 그렇지 않은 경우에 더 낫다는 것보다 낫다는 것을 발견했습니다.

우리가 TDD를하지 않는다고 가정합니까?

TDD를 연습하더라도 코드 검토를 수행하는 동안 테스트가 필요하다는 것을 알고 있다면 가지고 있지 않은 테스트를 작성하는 것이 어떻습니까?

찬성

• 검토중인 코드에 중점을 둡니다.
• 때때로 사람들이 참여하지 않으면 코드 검토가 행 아웃과 채팅 시간이됩니다. 테스트를 작성하면 모든 사람이 검토중인 코드에 대해보다 적극적으로 생각할 수 있습니다.
• 팀의 더 많은 주니어 멤버는 시험 작문 경험을 통해 배울 수있는 기회를 갖게됩니다.
• 팀에서 자신이 모르는 재능을 식별 할 수 있습니다.

더 많은 테스트가 더 많은 코드로 이어질 수 있다는 것이 실제로 단점입니까? 테스트가 필요하고 테스트에 코드가 필요한 경우 이제 테스트를 해보면 좋습니다 .

경고

팀의 일부는 다른 것에 집중해야 할 수도 있습니다. 우선 순위가 산만 해 지거나 코드 검토가 일정을 초과하는 경우 실제 테스트 작성을 제한하거나 잘라 내야합니다. 그러나 코드 검토는 반드시 작성해야하는 테스트를 식별 할 수 있으며, 아마도 작성자가 나중에 완료하기 위해 스텁 될 수 있습니다.

이것은 한 가지 경고와 함께 멋진 아이디어입니다. 개발자 필기 테스트를 검토 자 필기 테스트로 대체하지 마십시오. 검토자가 코드를 어기는 코너 케이스 및 입력을 찾도록하십시오. 다시 말해, 원래 개발자가 생각하지 않은 새로운 테스트 를 작성하도록하십시오.

특성화 테스트 작성은 작성하지 않은 코드 조각을 이해하는 데 매우 훌륭한 방법입니다. 검토자가 코드에서 추가 테스트를 수행하도록하면 코드 작동 방식, 코드 중단 방법 및 개선 방법에 대해 훨씬 더 잘 이해할 수 있습니다. 항상 코드 범위를 늘립니다.

이것들은 모두 내 책에서 이겼습니다.

나는 그 아이디어가 완전히 장점이 없다고 생각하지는 않지만, TDD 등의 주요 이점은 문제가 조기 에 발견된다는 것 입니다. 또한 개발자는 어느 코너 케이스에 특별한주의가 필요한지를 파악하는 것이 가장 좋습니다. 이것이 코드 검토까지 남아 있으면이 지식이 손실 될 위험이 있습니다.

코드 검토 중에 테스트를 작성하면 기존의 수동 테스트와 동일한 문제가 발생합니다. 비즈니스 규칙에 대한 이해는 실사와 마찬가지로 개발자마다 다를 수 있습니다.

더 심각한 버그를 잡아야하는 테스트 기능이 더 업스트림에 있음을 알고 있다면 개발자가 코드를 잘 테스트 할 것인지에 대한 오래된 토론도 있습니다.

@RobbieDee의 답변에 동의하지만 추가 할 것이 조금 더 있습니다.

이 아이디어가 정말 마음에 든다면 동일한 사람들이 코드 전에 테스트를 작성하여 사용자 스토리의 실행 가능한 승인 기준으로 작성하지 않는 이유는 무엇입니까?

그것은 똑같은 일을하고, 피드백을 짧게 유지하고 모든 사람들이 이야기에 대해 토론하게합니다. 더 큰 가치가 있다고 생각합니다.

단점은 끝없는 승인 기준 회의의 위험입니다. 그 문제.

OP는 어렵거나 알고리즘이 많은 기능에 대한 자세한 내용을 레이아웃하는 편집을 추가했습니다.

이에 대한 응답으로 문제와 해결책에 더 많은 관심을 기울이는 본능이 좋다고 덧붙입니다. 모든 사람들이 실제로 구현하기 어려운 코드와 테스트를 볼 때까지 여러 사람과 일대일로 페어링 할 수도 있습니다. 각각 새로운 아이디어를 버리고 더 많은 가치를 더합니다.

페어링이나 더 많은 사람들과 같은 몹 프로그래밍이라고하는 아이디어가 있습니다. 이것은 거의 당신이 말하고있는 것이지만 나중에 공식적인 검토보다는 글을 쓸 때 도움이됩니다. 이것은 모든 사람을위한 것이 아니며, 강력한 드라이버 (리더)가 필요하거나 서로 및 프로세스에 매우 편안한 팀을 요구할 수 있습니다.

사실 폭도 프로그래밍을 한 후에는 많은 사람들이 문제를보고 개선을 제안하는 것과 같은 많은 장점을 가질 것이라고 생각합니다. 그렇다면 팀이 편안하게 운영되는 것이 도움이 될 수 있지만 실제로 필요한 것을 유지하려고 노력할 것입니다. 팀의 속도를 늦출 수 있다고 생각할 때 최소로 줄어 듭니다.

당신이 말했듯이, 당신이 TDD 팀을 운영하고 있다면, 코드가 이미 테스트 되었기 때문에 이것이 무의미합니다.

전반적으로 나는 이것이 이것이 좋은 아이디어라고 생각하지는 않지만, 그것은 현재의 접근법과 당신에게 효과가있는 것에 달려 있습니다. 기본적으로, 내가 본 문제는 테스트의 "짧은 피드백 루프"이점을 잃어버린다는 것입니다. 새로운 코드를 작성하면서 무언가를 깨는 순간 즉각적인 알림을받는 것은 테스트가 실제로 빛나는 곳입니다. 코드 검토까지 테스트를 연기한다면 기본적으로 "우리는 더 적은 시간에 더 적은 수의 사람들과 함께이 문제를 일찍 해결할 수 있었지만 적어도 우리 모두는 무언가를 배웠을 것"이라고 말합니다. 사람들이 검토를 위해 테스트 코드를 제출하도록하는 것이 좋으며 테스트의 정확성과 유지 관리 가능성을 판단해야합니다. 결국 코드 검토는 코드 작성이 아니라 검토를위한 것입니다.

반면에, 검토하는 동안 테스트 / 코드를 사용하여 FIDDLE하는 것이 좋습니다. 무언가를 끊으십시오. if 조건을 주석 처리하십시오. 부울을 리터럴 true / false로 바꿉니다. 테스트가 실패했는지 확인하십시오.

그러나 네, 결국에는 코드와 함께 테스트를 작성한 다음 한 번에 검토하는 것이 좋습니다.

코드 검토에서 수행중인 작업에 따라 다릅니다. 그 단계에서 테스트를 작성해야하는 두 가지 주된 이유가 있다고 생각합니다.

• 먼저 코드 검토 중에 리팩토링을 수행하고 적용하려는 리팩토링의 종류를 포괄 할 수있는 단위 테스트가 충분하지 않은 경우 해당 테스트를 추가하십시오.

• 둘째, 코드에 버그가있는 것처럼 보이며이를 증명하거나 반증하려는 경우 테스트를 작성하십시오.

두 경우 모두 현재 존재하지는 않지만 테스트가 필요하다는 것을 나타냅니다. 물론 이러한 종류의 테스트를 검토 자 또는 원래 작성자가 작성해야하는 경우 팀 문화에 따라 달라질 수 있지만 누군가 테스트를 작성해야합니다.

사실, 나는 이것이 "복잡하고 과학적인 알고리즘"에 적합한 "코너 케이스"라고 생각하지 않습니다. 반대로, 이것은 어느 정도의 품질을 기대하는 모든 종류의 소프트웨어에 적합합니다.

아뇨,하지 마십시오. TDD가 끔찍하다고 생각하게 할 것입니다.

@ k3b는 질문에 대한 의견에 맞습니다. TDD 스타일 프로세스를 통해 작성된 코드는 테스트없이 작성된 코드와 다르게 보이고 상호 작용하는 경향이 있습니다. 테스트되지 않은 코드에 (좋은) 테스트를 추가하면 일반적으로 코드의 리팩토링을 통해 의도와 이동 부분을 명확히해야합니다.

코드를 작성한 후 테스트를 추가하면 TDD의 장점 인 아키텍처 측면을 놓치게됩니다 (제 생각에는 주요 이점 중 하나입니다). 뿐만 아니라 코드에 거의 익숙하지 않은 다른 사람에게 이미 추가하기 어려운 테스트를 추가하도록 요구하고 있습니다.

테스트를 추가 한 사람은 코드를 크게 리팩터링해야하거나 테스트 할 수없는 코드를 테스트하기 위해 매우 열심히 노력해야합니다. 어느 쪽이든, 그들은 경험을 즐기지 않을 것입니다. 이것이 고전적인 TDD가 아닐지라도 그들은 그렇게 볼 수 없으며 TDD를 한 번에 모두 해제 할 수 있습니다.

(TDD 프로세스를 이미 수행하고 있다면 코드 검토 중에 추가 테스트를 작성하는 것이 나쁘지 않지만 내 경험에 따르면 테스트가 잘 작성된 경우 추가 테스트를 제출하는 사람에게 추가 테스트를 설명하는 것만 큼 쉽습니다. 검토 용 코드를 작성하여 작성하도록합니다.)

코드 검토 중 단위 테스트는 개발 중 단위 테스트를 대체 할 수 없습니다.

당신이 제안하는 것은 직관적으로 많은 의미가 있습니다. 에 대한 리뷰는 무엇입니까? 코드가 좋은지 확인하십시오. 테스트 란 무엇입니까? 코드가 좋은지 확인하십시오. 그렇다면 왜 두 가지를 결합하지 않습니까?

이유는 다음과 같습니다.

테스트중인 코드를 가져 오는 것은 어려운 일입니다. 의도 된 것 중 하나에서 작동 하는 코드 작성 은 하나의 것입니다. 효과적이고 효율적으로 테스트 할 수있는 코드를 작성하는 것도 또 다른 방법입니다. 이제 코드가 "실제 작업"과 "테스트"라는 두 가지 시나리오에서 실행된다는 사실은 훨씬 더 큰 유연성을 요구하고 해당 코드가 의미있는 방식으로 자체적으로 작동 할 수 있어야합니다.

테스트 할 수 있도록 코드를 작성하는 것은 추가 작업과 기술입니다. 테스트 가능성을 염두에두고 작성되지 않았을 때 테스트 가능성에 대한 다른 사람의 코드를 리팩터링 하는 것은 중요한 작업이 될 수 있습니다.

개발자와 검토 자 간의 노력이 중복됩니다. 아마도, 개발자는 이상없이 검토를 위해 자신의 코드를 전달하지 않는 일부 가 작동하고 있다는 자신감의 수준. 그는 이미 코드를 테스트해야합니다. 이제 다양한 수준과 테스트 범위가 있습니다. QA는 개발자 와 검토 자 후에 코드를 테스트합니다 . 그러나 개발자와 검토 자에게 적합하다고 생각되는 범위에 관계없이 개발자는 코드를 해당 수준으로 한 번 테스트하는 방법을 알아낼 수는 없지만 테스트 를 버리고 재현하기가 어려워 검토 자를 가져옵니다. 다시 테스트를 개발이번에는 자동화되고 재현 가능한 것들입니다. 당신은 데있어 모두 한 번 제대로 한 번 잘 - 그들의이 같은 테스트를 작성에 시간을 투자합니다.

검토를 훨씬 더 길고 힘든 단계로 바꾸고 있습니다. 테스트가 검토 프로세스의 주요 부분 인 경우 일부 테스트가 실패하면 어떻게됩니까 ? 검토자가 테스트를 모두 실행해야하므로 코드도 디버깅해야합니까? 아니면 한 번의 필기 시험과 다른 시험에 합격 할 수 있는가?

때로는 서로 직교하는 전체 테스트를 작성할 수 있으므로 탁구를 불필요합니다. Reviewer는 12 개의 테스트를 작성하고 그 중 절반은 실패하고 개발자는 버그를 수정하고 모든 테스트는 계속 유효합니다. 그러나 ... 많은 시간에 차단기 버그, 재 설계 및 API 변경이 필요한 버그 등이 있습니다. 검토 자와 개발자간에 테스트를 전달하는 책임을 맡고 있다면 실제로는 검토 단계에 있지 않습니다. 아직 개발 중입니다.

테스트를 작성해야한다고해서 더 철저한 검토가 이루어지지는 않습니다. 기본적으로 더 깊게 갈수록 더 많은 테스트를 작성 해야하며 시스템에 깊숙히 들어가야하는 어려운 테스트 일 것입니다 .

인센티브가있는 테스트를 작성하는 개발자와 비교해보십시오. 중요한 테스트를 작성하지 않으면 검토자가이를 검토에서 지적합니다.

리뷰어 조차도 코드의 철저한 테스트 를 거쳐야하는 경우 시스템에 대해 더 잘 이해할 것입니다. 그러면 심층 테스트 작성을 중단하고 코드 검토를 확인하는 시간을 스스로 결정할 필요가있는 경우 시스템을 더 잘 이해할 수 있습니다.

개발자가 단위 테스트를 작성하지 않으면 검토 자도 작성하지 않습니다. 테스트를 일반적인 관행으로 채택하는 데 많은 장애물이 있습니다. 압력이 너무 높을 수 있으며 코드 기반을 테스트하기가 어렵습니다. 어쩌면 당신은 테스트 경험이 많지 않고 학습 곡선을 감당할 수 없다고 생각할 것입니다. 어쩌면 테스트를 작성하는 사람들에게 위협 메모를 보내는 도끼 살인자가있을 수 있습니다. 몰라요!

그러나 원인이 무엇이든 상관없이 검토 자와 개발자에게 똑같이 적용되는 것이 좋습니다. 팀이 스트레스를받는 경우 검토자는 개발자보다 더 많은 시간을 갖지 못합니다 (그렇다면 개발자가 스트레스를받지 않도록 작업을 재배포하십시오 ). 아무도 단위 테스트를 잘 작성하는 방법을 모른다면, 검토자는 아마 그렇게하지 않을 것입니다 (그렇다면 그녀는 앉아서 팀원들에게 가르쳐야합니다 ).

이 제안은 한 동료에서 다른 동료에게 벅을 전달하려는 것처럼 들립니다. 그리고 한 사람이 테스트를 수행 할 수있는 유일한 사람이고 다른 사람이 할 수없는 상황을 만드는 것은 실제로 어렵고 건강하지 않기 때문에 가장 잘 작동하는 방법을 보지 못하고 있습니다. 모든 테스트.

무엇 합니까 작업 것은 물론 검토 커버 테스트를 가진. 개발자가 이미 10 개의 테스트를 작성했다면 개발자가 작성하지 않은 경우보다 검토자가 다른 10 개를 제안하는 데 도움이 될 수 있습니다.

그리고 코너 케이스 테스트가 중요한 작업이라면, 팀 전체에 더 널리 배포하는 것이 합리적 일 수 있습니다. ** 코드를 처음에 테스트 할 수있게되면 더 많은 테스트를 작성 하는 것이 훨씬 쉬워집니다. **

검토는 코너 사건 을 발견 하기에 좋은 시간 입니다. 그리고 리뷰어가 뛰어 들어 코너 케이스에 대한 테스트를 작성할 수 있다면, 이봐-더 나아! 그러나 일반적으로, 리뷰어가 개발자 가 생각하기에 좋지 않은 것으로 테스트를 작성할 수 있다고 가정합니다 .