나중에 주석 처리되는 경향이 있거나 통합 테스트가 더 중요하기 때문에 단위 테스트를 작성하지 않는 것이 합리적입니까?

나는 동료와 단위 / 통합 테스트를 논의 선수로 흥미있는 경우에 만들어 에 대한 단위 테스트를 작성합니다. 나는 큰 단위 테스트 (주로 JUnit) 지지자이지만 다른 흥미로운 점을 들으면서 다른 사람들의 의견을 듣고 싶습니다.

그의 요점을 요약하면 다음과 같습니다.

• 주요 코드 변경 (새로운 POJO, 주요 응용 프로그램 리팩토링 등)이 발생하면 단위 테스트는 재 작업이 아닌 주석 처리되는 경향이 있습니다.
• 사용 범위를 다루는 통합 테스트에 더 많은 시간을 할애하므로 소규모 테스트는 중요하지 않습니다.

이것에 대한 생각? 통합 테스트는 적어도 귀중한 것으로 들리지만 여전히 프로 단위 테스트입니다.

단위 테스트가 너무 자주 잘못된 것을 테스트 하기 때문에 친구와 함께하는 경향이 있습니다.

단위 테스트는 본질적으로 나쁘지 않습니다. 그러나 종종 입력 / 출력 흐름이 아닌 구현 세부 사항을 테스트합니다. 이런 일이 발생하면 완전히 무의미한 테스트로 끝납니다. 내 자신의 규칙은 좋은 단위 테스트는 당신이 무언가를 깨뜨렸다는 것을 알려줍니다. 나쁜 단위 테스트는 단지 당신이 무언가를 바꿨다는 것을 말해줍니다.

내 머리 꼭대기의 예는 몇 년 전에 WordPress에 집어 넣은 테스트입니다. 테스트되는 기능은 서로 호출되는 필터를 중심으로 진행되었으며 테스트 결과 콜백이 올바른 순서로 호출되는지 확인했습니다. 그러나 (a) 콜백이 예상 순서대로 호출되는지 확인하기 위해 체인을 실행하는 대신 테스트는 (b) 처음에는 노출되어서는 안될 내부 상태를 읽는 데 중점을 두었습니다. 내부를 변경하면 (b) 빨간색으로 바뀝니다. 반면 (a) 내부 변경으로 인해 예상 결과가 깨지는 경우에만 빨간색으로 바뀝니다. (b) 분명히 제 생각에는 무의미한 시험이었습니다.

당신은 외부 세계에 몇 가지 방법을 노출하는 클래스가있는 경우, 내보기에 시험에 대한 올바른 것은 후자의 방법이 있습니다 만은 . 내부 논리도 테스트하는 경우 복잡한 테스트 방법을 사용하거나 변경하려는 경우 항상 중단되는 단위 테스트를 사용하여 내부 논리를 외부 세계에 노출시킬 수 있습니다.

모든 말로, 당신의 친구가 당신이 제안한 것처럼 단위 테스트 자체에 대해 비판적이라면 놀랄 것입니다. 오히려 그는 실용적입니다. 즉, 그는 작성된 단위 테스트가 실제로 무의미하다는 것을 관찰했습니다. 인용 : "단위 테스트는 재 작업보다는 주석 처리되는 경향이 있습니다". 나에게는 암묵적 인 메시지가 있습니다. 재 작업이 필요한 경향이 있다면 빨려 들기 때문입니다. 그렇게 가정하면 두 번째 제안은 다음과 같습니다. 개발자는 잘못하기 어려운 코드, 즉 통합 테스트를 작성하는 데 시간을 덜 소비하게됩니다.

따라서 그것은 더 나아지는 것에 관한 것이 아닙니다. 그것은 잘못되기가 훨씬 쉽고 실제로 실제로 잘못되는 경우가 많습니다.

주요 코드 변경이 발생하면 단위 테스트는 재 작업이 아닌 주석 처리됩니다.

당연히 모든 기존 테스트에 대해 언급 할 때 모든 테스트가 "녹색"이된다고 생각하는 훈련되지 않은 카우보이 코더들과 함께. 재 작업 단위 테스트는 처음에 작성하는 것과 같은 양의 규율이 필요하므로 여기서 수행해야 할 것은 팀의 "완료된 정의"입니다.

더 작은 범위의 테스트를 덜 중요하게 만드는 사용 사례를 다루는 통합 테스트에 시간이 더 많이 걸립니다.

그것은 완전히 잘못되거나 완전히 옳지 않습니다. 유용한 통합 테스트를 작성하려는 노력은 어떤 종류의 소프트웨어를 작성 하느냐에 달려 있습니다. 통합 테스트가 단위 테스트만큼 쉽게 작성 될 수있는 소프트웨어가있는 경우, 여전히 빠르게 실행되고 코드에 대한 유용한 정보를 제공 할 수 있습니다. 그러나 많은 시스템에서 이러한 세 가지 점을 통합 테스트로 쉽게 충족시킬 수 없다는 것을 알았으므로 단위 테스트를 수행하려고 노력해야합니다.

나는 당신의 동료의 주장을 받아들입니다.

1. 단위 테스트가 주석 처리되면 누군가 게으 르기 때문입니다. 그것은 단위 테스트의 결함이 아닙니다. 그리고 당신이 변명으로 게으름을 사용하기 시작하면 약간의 노력이 필요한 거의 모든 연습에 대해 논쟁 할 수 있습니다.
2. 제대로하고 있다면 단위 테스트에 시간이 오래 걸리지 않아도됩니다. 그들은 당신이 더 중요한 일을하는 것을 방해하지 않습니다. 깨진 코드를 수정하는 것이 다른 무엇보다 중요하다는 데 모두 동의한다면 단위 테스트는 매우 중요합니다. 사후 조건을 테스트하는 쉬운 방법입니다. 그것없이, 당신은 당신이 사후 조건 보증을 만났다는 것을 어떻게 알 수 있습니까? 그리고 그렇지 않으면 코드가 손상됩니다.

단위 테스트에 대한 다른 더 강력한 주장이 있습니다. 글쎄, 그들에 대해 정확히 반대하지는 않습니다. DHH의 테스트 유도 설계 손상 부터 시작하십시오 . 그는 재미있는 작가이기 때문에 읽어보십시오. 내가 가져간 것 :

단위 테스트를 수용하기 위해 큰 디자인 변경을 수행하면 프로젝트의 다른 목표를 방해 할 수 있습니다. 가능하면 공정한 사람에게 접근하기 쉬운 방법을 문의하십시오. 테스트 가능성이 높은 코드를 이해하기 어려운 경우 단위 테스트에서 얻을 수있는 모든 이점을 잃을 수 있습니다. 너무 많은 추상화에 대한인지적인 오버 헤드는 속도를 늦추고 새는 실수를 더 쉽게 만듭니다. 할인하지 마십시오.

뉘앙스와 철학을 원한다면 많은 훌륭한 자료가 있습니다.

• Ian Bicking의 테스트는 유해한 것으로 간주됩니다 (테스트로는 충분하지 않습니다. 테스트는 코드를 아름답게 만들지 않습니다).
• Dan Manges의 증가하는 코드 적용 범위가 해로울 수 있습니다 (코드 적용 범위를 메트릭으로 사용한다고해서 유용한 작업이 있는지는 알 수 없습니다.)
• 그렇다면 단위 테스트를 작성하지 않은 것에 대한 좋은 주장이 있습니까? 스택 오버플로에서 닫힙니다 . (과도하게, 비용이 인식되지 않고, 교활한 버그를 찾지 못하고, 아름다운 코드 (Bicking과 같은 Kinda) 등을 대체하지 않음)

주요 코드 변경 (새로운 POJO, 주요 응용 프로그램 리팩토링 등)이 발생하면 단위 테스트는 재 작업이 아닌 주석 처리되는 경향이 있습니다.

하지마 당신이 그 일을하는 사람을 찾으면, 살해하고 그들이 재생산되지 않도록하십시오. 아이들은 결함이있는 유전자를 물려받을 수 있습니다. 내가 CSI TV 쇼를 볼 때 볼 수있는 열쇠는 모든 곳에서 오해의 소지가있는 DNA 샘플을 뿌려주는 것입니다. 이렇게하면 DNA 테스트의 비용이 많이 들고 시간이 많이 걸리는 특성을 고려할 때 범죄 현장을 너무 많은 소음으로 오염시킬 수 있습니다.

단위 테스트는 재 작업보다는 주석 처리되는 경향이 있습니다.

이 시점에서 코드 검토 프로세스에 "단위 테스트 수정"이 표시되고 더 이상 문제가되지 않습니다. 코드 검토 프로세스가 제출 된 코드에서 이러한 종류의 주요 결함을 발견하지 못하면 문제가됩니다.

주요 코드 변경 (새로운 POJO, 주요 응용 프로그램 리팩토링 등)이 발생하면 단위 테스트는 재 작업이 아닌 주석 처리되는 경향이 있습니다.

나는 항상 리팩토링과 기능 변경을 분리하려고 노력합니다. 두 가지를 모두 수행해야 할 때 일반적으로 리팩토링을 먼저 수행합니다.

기능을 변경하지 않고 코드를 리팩토링 할 때 기존 단위 테스트는 리팩토링이 실수로 기능을 중단하지 않도록하는 데 도움이됩니다. 따라서 그러한 커밋의 경우 단위 테스트 비활성화 또는 제거가 주요 경고 신호로 간주됩니다. 코드를 검토 할 때 그렇게하지 말라고 개발자에게 지시해야합니다.

기능을 변경하지 않는 변경으로 인해 결함이있는 단위 테스트로 인해 단위 테스트가 계속 실패 할 수 있습니다. 변경하는 코드를 이해하면 이러한 단위 테스트 실패의 원인은 일반적으로 명백하고 수정하기 쉽습니다.

예를 들어, 함수가 세 개의 인수를 취하는 경우, 함수에 대한 첫 두 인수 사이의 상호 작용을 다루는 단위 테스트는 세 번째 인수에 유효한 값을 제공하지 않았을 수 있습니다. 단위 테스트의 이러한 결함은 테스트 된 코드의 리팩토링에 의해 노출 될 수 있지만 코드가 수행해야하는 작업과 단위 테스트가 수행하는 작업을 이해하면 쉽게 고칠 수 있습니다.

기존 기능을 변경하는 경우 일반적으로 일부 단위 테스트도 변경해야합니다. 이 경우 단위 테스트를 통해 코드가 의도 한대로 기능을 변경하고 의도하지 않은 부작용이 없는지 확인할 수 있습니다.

버그를 수정하거나 새로운 기능을 추가 할 때는 일반적으로 더 많은 단위 테스트를 추가해야합니다. 이를 위해 먼저 단위 테스트를 커밋하고 나중에 버그 수정 또는 새로운 기능을 커밋하는 것이 도움이 될 수 있습니다. 따라서 새로운 단위 테스트가 이전 코드와 함께 전달되지 않고 최신 코드와 함께 전달되는지 쉽게 확인할 수 있습니다. 그러나 이러한 접근 방식이 완전히 결점이없는 것은 아니기 때문에 새로운 단위 테스트와 코드 업데이트를 동시에 수행하는 데 유리한 주장도 있습니다.

사용 범위를 다루는 통합 테스트에 더 많은 시간을 할애하므로 소규모 테스트는 중요하지 않습니다.

이것에는 진실의 요소가 있습니다. 소프트웨어 스택의 상위 계층을 대상으로하는 테스트를 통해 소프트웨어 스택의 하위 계층을 다룰 수있는 경우 코드를 리팩토링 할 때 테스트가 더 도움이 될 수 있습니다.

단위 테스트와 통합 테스트의 정확한 차이점에 대해서는 동의하지 않을 것이라고 생각합니다. 그리고 한 개발자가 유용한 테스트 사례라고 동의 할 수있는 한 한 개발자가 단위 테스트를 호출하고 다른 개발자가 통합 테스트를 호출하는 테스트 사례가 있는지 걱정하지 않습니다.

시스템은 항상 비즈니스 가치가있는 예상대로 작동하는지 확인하기 위해 통합 테스트를 수행합니다. 단위 테스트가 항상 그런 것은 아닙니다. 예를 들어 단위 테스트는 데드 코드를 테스트 할 수 있습니다.

정보를 제공하지 않는 모든 테스트는 낭비라고 말하는 테스트 철학이 있습니다. 코드가 작동하지 않을 때 단위 테스트는 항상 (또는 거의 항상) 녹색이되어 정보를 거의 또는 전혀 제공하지 않습니다.

모든 테스트 방법이 불완전합니다. 일부 메트릭으로 100 % 적용 범위를 확보하더라도 거의 모든 가능한 입력 데이터 세트를 거치지 않습니다. 따라서 단위 테스트가 마술이라고 생각하지 마십시오.

단위 테스트를 수행하면 코드가 향상된다는 주장을 자주 보았습니다. 제 생각에, 단위 테스트가 코드에 가져 오는 개선은 코드에 익숙하지 않은 사람들이 코드를 작고 잘 정리 된 부분으로 나눌 수있게하는 데 있습니다. 일반적으로 작고 잘 구성된 부분으로 코드를 디자인하는 데 익숙하다면 더 이상 단위 테스트가 필요하지 않을 수도 있습니다.

단위 테스트의 정도와 프로그램의 규모에 따라 엄청난 양의 단위 테스트가 발생할 수 있습니다. 그렇다면 큰 변화가 더 어려워집니다. 큰 변화로 인해 단위 테스트가 실패하면 변경을 거부하거나 많은 테스트를 수정하기 위해 많은 작업을 수행하거나 테스트를 버릴 수 있습니다. 어떤 선택도 이상적이지 않습니다.

단위 테스트는 도구 상자의 도구입니다. 그들은 당신에게 봉사하기 위해 거기에 있습니다. 적어도 당신이 넣은만큼 꺼내십시오.

단위 테스트는 분명히 일부 지지자들이 주장하는 은색 총알이 아닙니다. 그러나 일반적으로 비용 / 이익 비율은 매우 긍정적입니다. 그들은 당신의 코드를 "더 나은"것으로 만들지 않을 것입니다. "더 나은"은 "테스트 가능성"이 의미하는 것보다 훨씬 많은 요소를 가지고 있습니다. 그러나 그들은 당신이 생각한 모든 경우와 사용법에서 작동하는지 확인하고 대부분의 버그 (아마도 더 사소한 버그)를 제거합니다.

단위 테스트의 가장 큰 장점은 코드를보다 유연하고 탄력적으로 변경하는 것입니다. 기능을 리팩터링하거나 추가 할 수 있으며 아무 것도 깨지 않았 음을 확신 할 수 있습니다. 이것만으로도 대부분의 프로젝트에 가치가 있습니다.

친구가 지적한 사항 참조 :

1. POJO를 추가하면 단위 테스트가 중단되면 아마도 매우 잘못 작성된 것입니다. POJO는 일반적으로 도메인에 대해 이야기하기 위해 사용하는 언어이며, 해결하는 문제는 분명히 전체 비즈니스 논리를 의미하며 프리젠 테이션 코드는 변경되어야합니다. 프로그램의 해당 부분이 변경되지 않도록 보장하는 것을 기대할 수는 없습니다 ...

2. 사람들이 의견을 말했기 때문에 단위 테스트가 나쁘다는 불만은 사람들이 안전띠를 착용하지 않기 때문에 안전 벨트가 나쁘다는 불만입니다. 테스트 코드를 언급하고 무언가를 깨 뜨리면 상사와 매우 심각하고 불쾌한 대화를 끝내야합니다 ...

3. 통합 테스트는 단위 테스트보다 훨씬 우수합니다. 질문 없음. 특히 제품을 테스트하는 경우. 그러나 단위 테스트가 제공하는 것과 동일한 가치, 적용 범위 및 정확성을 보장하는 훌륭하고 포괄적 인 통합 테스트를 작성하는 것은 매우 어렵습니다.

단위 테스트에 대한 하나의 주장 만 생각할 수 있으며 꽤 약합니다.

단위 테스트는 나중에 코드를 리팩토링하거나 변경할 때 그 가치가 대부분임을 보여줍니다. 기능을 추가하고 깨진 부분이 없도록 보장하는 데 소요되는 시간이 크게 단축되었습니다.

그러나 처음에는 테스트를 작성하는 데 소요되는 비용이 적습니다.

따라서 : 프로젝트가 짧고 지속적인 유지 보수 / 업데이트가 필요하지 않은 경우 테스트 작성 비용이 그 이점보다 클 수 있습니다.