통합 테스트는 설계를 어떻게 비판합니까?


38

JB Rainsberger의 블로그 게시물 에서 통합 테스트에 대해 읽었으며 디자인에서 통합 테스트가 어떤 방식으로 더 가혹한 지 궁금하십니까?

우리는 더 큰 통합 테스트를 작성하며, 마이크로 테스트만큼 심하게 디자인을 비판하지 않습니다.


3
문제는 혼란 스럽다. "통합 테스트가 더 가혹한 방법"... "통합 테스트는 더 크며 우리의 디자인을 가혹하게 비판하지 않습니다"-지금 무엇?
AnoE


"통합 테스트"! = "통합 테스트". 알아. 나도 마음에 들지 않지만 그 단어의 의미입니다. "integration tests"= "통합 지점을 검사하는 테스트 (통합 사물없이)", "integrated tests"= "사물을 통합하고 통합 된 전체를 단일 사물로 검사하는 (대형) 테스트" 이런 식으로,이 용어들은 서로 반대가됩니다.
JB Rainsberger

답변:


46

미세 테스트는 좋은 디자인으로 이어질 수 있습니다 . 좋은 작은 테스트를 작성하면 소량의 코드를 의도적으로 테스트하고 모의 객체 로 그 간격을 채 웁니다 . 이것은 낮은 커플 링 (서로 의존하지 않는 것)과 높은 응집력 (함께있는 것들)을 유지합니다. 이렇게하면 돌아가서 변경할 때 원하는 것을 담당하는 것을 쉽게 찾을 수 있으며 변경을 수행 할 때 문제가 발생할 가능성이 줄어 듭니다. 이것은 모든 디자인을 해결하지는 않지만 도움이 될 수 있습니다.

이러한 맥락에서, JB Rainsberger는 단위 테스트 작성에 어려움을 겪는다면 설계에 문제가있어 어려움을 야기 할 수 있으므로 테스트가 설계를 암시 적으로 비판하고 있다고 지적합니다. 그는 작은 테스트가 없으면 아키텍처를 유지하는 데 도움이되므로 통합 된 테스트에서는 캡처 할 수없는 좋은 디자인 패턴을 쉽게 벗어날 수 있기 때문에 이것이 좋은 것이라고 주장합니다.

업데이트 : Rainsberger는 아래에서 지적했듯이 마이크로 테스트는 단위 테스트와 동의어가되지 않았습니다. 또한 의사 소통 내용을 정확하게 파악할 수있는 자세한 답변을 제공합니다.


2
나는 당신의 대답에 원칙적으로 동의하지만 당신이 그것을 표현하는 방식은 아닙니다. 이 특정 질문을하는 사람은 "mocking", "coupling"및 "cohesion"이라는 용어의 의미를 알지 못할 가능성이 높으며 귀하의 답변에 해당 용어를 정의하지 않았습니다.
Robert Harvey

3
더 낫지 만 실제로 테스트 결과가 생각보다 단위 테스트에 더 많은 신용을 부여하고 있습니다. 단위 테스트는 대부분 코드의 테스트 가능성을 알려줍니다. 확실하게 긍정적 인 영향을 주지만 코드를 테스트 가능하게 만드는 것이 자동으로 더 나은 응집력과 결합 특성을 부여하는지 여부는 명확하지 않습니다. 또한 "단일 책임 원칙"과 혼동되는 "높은 응집력"을 가지고 있다고 생각합니다. 응집력은 "함께 속한 것"을 의미합니다 ( Wikipedia article 참조 ).
Robert Harvey

10
마지막으로 "마이크로 테스트"는 바람직한 용어가 아닙니다. 블로거가 자신의 기술 용어를 만들 때 나는 그것을 좋아합니다.
Robert Harvey

2
@RubberDuck : 마이크로 테스트 (약 16,900 개 결과) vs 유닛 테스트 (약 193,000,000 개 결과) . 근처에도 안. 단위를 테스트하고 함께 테스트 하더라도 여전히 1400 만 개의 결과를 얻습니다.
Robert Harvey

5
"마이크로 테스트"와 "단위 테스트"를 동일시하지 마십시오 (자세한 내용은 답변 참조). 그렇지 않으면, 당신이 내가 묘사하려는 것을 이해 한 것처럼 느낍니다.
JB Rainsberger

28

매우 짧은 버전 : 더 작은 테스트는 시스템의 작은 부분을 실행하기 때문에 프로그래머가 작성할 수있는 내용을 자연스럽게 제한하므로 피드백을 더 선명하게 (알기 쉽고 / 더보기 어렵게) 할 수 있습니다. 이것이 반드시 더 나은 디자인으로 이어지지는 않지만 오히려 디자인 위험을 더 빨리 발견 할 수있는 기회를 제공한다고 덧붙입니다.

먼저, "마이크로 테스트"라고 말할 때 나는 "작은 테스트"를 의미하며 더 이상은 없습니다. "단어 테스트"를 의미하지 않기 때문에이 용어를 사용합니다. "단위"를 구성하는 요소에 대한 논쟁에 휘말리고 싶지 않습니다. 신경 쓰지 않습니다 (적어도 여기 / 지금은 아닙니다). 두 사람은 아마도 "단위"보다 "작은"에 대해 더 쉽게 동의 할 것입니다. 그래서 저는이 아이디어의 새로운 표준 용어로 "마이크로 테스트"를 점차 채택하기로 결정했습니다.

"액션"부분에서 시스템의 더 큰 부분을 실행하는 테스트를 의미하는 더 큰 테스트는 더 작은 테스트만큼 명확하거나 완벽하게 디자인을 비판하지 않는 경향이 있습니다. 주어진 테스트 그룹을 통과 할 수있는 모든 코드베이스 세트를 상상해보십시오. 즉, 코드를 재구성 할 수 있으며 여전히 해당 테스트를 통과합니다. 더 큰 테스트의 경우이 세트가 더 큽니다. 작은 테스트의 경우이 세트가 더 작습니다. 다르게 말하면, 테스트가 작을수록 디자인이 더 많이 구속되므로 디자인이 적을수록 통과 할 수 있습니다. 이런 식으로 마이크로 테스트는 디자인을 더 비판 할 수 있습니다.

나는 당신이 듣고 싶지 않지만 듣고 싶어하는 것을 직접 알려주고 다른 사람들이 편안하게 느끼지 않는 방식으로 긴급 성을 전하기 위해 당신에게 소리 치는 친구의 이미지를 불러 일으키기 위해 "더 가혹하게"말합니다 하기. 반면에 통합 테스트는 조용히 있고 더 이상 문제를 해결할 시간이나 에너지가 없을 때 문제를 암시합니다. 통합 테스트를 통해 양탄자 아래에서 설계 문제를 쉽게 해결할 수 있습니다.

더 큰 테스트 (통합 테스트와 같은)를 사용하면 프로그래머는 주로 멍청함을 통해 문제를 겪는 경향이 있습니다. 어쨌든 테스트를 통과하는 엉킨 코드를 자유롭게 작성할 수는 있지만 다음 코드로 넘어가는 순간 그 코드에 대한 이해가 빨리 사라집니다. , 다른 사람들은 엉킨 디자인을 읽는 데 어려움을 겪고 있습니다. 여기에는 통합 테스트에 의존 할 위험이 있습니다. 작은 테스트 (마이크로 테스트와 같은)를 사용하면 프로그래머는 대부분 과잉 사양을 통해 문제를 겪는 경향이 있습니다. 일반적으로 이전 테스트의 복사 / 붙여 넣기로 관련이없는 세부 사항을 추가하여 테스트를 과도하게 제한합니다. 구석으로. 좋은 소식: 몇 시간 또는 며칠 후에 테스트에서 외부 세부 사항을 제거하는 것이 훨씬 쉽고 안전하다는 것을 알게되었습니다. 실수가지나면서 과잉 지정은 점점 더 명백한 피해를 더 빨리 미치며, 경고 프로그래머는 문제를 수정해야한다는 것을 미리 알게됩니다. 나는 이것이 강점이라고 생각한다 : 나는 문제를 더 일찍 발견하고 그러한 문제가 기능을 추가 할 수있는 능력을 교란하기 전에 문제를 해결한다.


단위 테스트가 실제 코드보다 모의에 더 의존하는 문제에 대해 당신은 무엇을합니까?
Zan Lynx

@ ZanLynx 나는 이것에 대해 길게 작성했습니다. 여기에서 시작하십시오 : blog.thecodewhisperer.com/series#integrated-tests-are-a-cam
JB Rainsberger

9

그는 통합 테스트보다 단위 테스트를 통해 우수한 소프트웨어 디자인을보다 잘 알 수 있음을 의미합니다.

이유는 다음과 같습니다. 단위 테스트를 작성하면 단위 테스트 가능한 코드를 작성하게됩니다. 단위 테스트 가능 코드는 단위 테스트가없는 코드보다 더 나은 디자인 인 경향이 있습니다.

통합 테스트는 소프트웨어를 서로 연결하는 내부 인터페이스가 아니라 소프트웨어의 외부 레이어 만 테스트하기 때문에 코드에 동일한 방식으로 정보를 제공하지 않습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.