[java] 왜 테스트를 위해 JUnit을 사용합니까?

우리는 프로그램 행동의 정확성을 검증하기위한 테스트를 작성합니다.

사용자의 눈을 사용하여 출력 명령문의 내용을 검사하여 프로그램 동작의 정확성을 확인하는 것은 수동 또는보다 구체적으로 시각적 프로세스입니다.

당신은 그것을 주장 할 수 있습니다

육안 검사가 작동 합니다.이 시나리오에서 코드가 의도 한대로 작동하는지 확인하고 코드가 올바른지 확인하면 좋습니다.

우선 코드가 올바르게 작동하는지에 관심이 있다는 것이 좋습니다. 좋은 일입니다. 당신은 곡선보다 앞서 있습니다! 슬프게도이 방법에는 문제가 있습니다.

육안 검사의 첫 번째 문제는 코드의 정확성을 다시 확인할 수 없다는 점에서 용접 사고가 심하다는 것입니다.

두 번째 문제는 사용 된 한 쌍의 눈이 눈 소유자의 뇌와 밀접하게 연결되어 있다는 것입니다. 코드 작성자가 육안 검사 프로세스에 사용 된 눈을 소유하는 경우 정확성을 검증하는 프로세스는 육안 검사자의 뇌에 내재 된 프로그램에 대한 지식에 의존합니다.

새로운 코 쌍이 들어 와서 코더의 두뇌와 제휴하지 않기 때문에 코드의 정확성을 검증하는 것은 어렵습니다. 두 번째 눈의 소유자는 문제의 코드를 완전히 이해하기 위해 코드의 원래 작성자와 대화 해야합니다 . 지식을 공유하는 수단으로서의 대화는 믿을 수 없을 정도로 악명 높습니다. 원래 코더를 새 쌍 눈에 사용할 수없는 경우 약점입니다. 이 경우 새로운 눈 쌍은 원래 코드를 읽어야합니다.

단위 테스트에서 다루지 않는 다른 사람의 코드를 읽는 것은 단위 테스트와 관련된 코드를 읽는 것보다 어렵습니다. 다른 사람의 코드를 읽는 것이 가장 까다로운 작업이지만 최악의 경우 소프트웨어 엔지니어링에서 가장 터무니없는 작업입니다. 구인 광고를 할 때 고용주가 프로젝트가 그린 필드 (또는 새로운) 프로젝트임을 강조하는 이유가 있습니다. 코드를 처음부터 작성하는 것이 기존 코드를 수정하는 것보다 쉬우므로 광고 된 작업이 잠재적 인 직원에게 더 매력적으로 보입니다.

단위 테스트를 통해 코드를 구성 요소 부분으로 나눕니다. 그런 다음 각 구성 요소에 대해 프로그램의 작동 방식을 알려주는 스톨을 설정했습니다 . 각 단위 테스트는 특정 시나리오에서 프로그램의 해당 부분이 어떻게 작동해야하는지에 대한 이야기를 제공합니다. 각 단위 테스트는 클라이언트 코드의 관점에서 수행되어야하는 작업을 설명하는 계약의 조항과 같습니다.

이것은 새로운 쌍의 눈이 문제의 코드에 대한 두 가지 가닥의 라이브 문서 와 정확한 문서를 가지고 있음을 의미합니다 .

먼저 코드 자체, 구현, 코드 수행 방식이 있습니다 . 둘째, 그들은 원래의 코더가이 코드 가 어떻게 행동 해야하는지에 대한 이야기를하는 공식적인 진술서에 기술 된 모든 지식을 가지고 있습니다 .

단위 테스트는 원래 작성자가 수업을 구현할 때 보유한 지식을 캡처하고 공식적으로 설명합니다. 클라이언트가 사용할 때 해당 클래스의 작동 방식에 대한 설명을 제공합니다.

쓸모없는 단위 테스트를 작성할 수 있고, 문제가되는 모든 코드를 다루지 않고, 오래되거나 오래되지 않은 등의 작업을 수행 할 수 있기 때문에이 작업의 유용성에 의문을 갖는 것이 맞습니다. 단위 테스트가 런타임에 코드의 출력문을 시각적으로 검사하는 지식이 풍부하고 양심적 인 저자의 프로세스를 모방 할뿐만 아니라 개선 할 수 있도록하려면 어떻게해야합니까? 먼저 단위 테스트를 작성한 다음 테스트를 통과하는 코드를 작성하십시오. 작업이 끝나면 컴퓨터가 테스트를 실행하도록하고, 작업에 가장 적합한 반복 작업을 수행하는 데 빠릅니다.

테스트 할 코드를 터치 할 때마다 테스트 품질을 검토하고 각 빌드에 대해 테스트를 실행하십시오. 테스트가 실패하면 즉시 수정하십시오.

테스트 빌드 프로세스를 자동화하여 프로젝트 빌드를 수행 할 때마다 테스트가 실행되도록합니다. 또한 테스트에서 다루고 실행하는 코드 비율을 자세히 설명하는 코드 적용 보고서 생성을 자동화합니다. 우리는 높은 비율을 위해 노력합니다. 일부 회사는 코드 변경 사항을 설명하기 위해 작성된 단위 테스트가 충분하지 않은 경우 코드 변경 사항을 소스 코드 제어에 체크인하지 못하게합니다. 일반적으로 두 번째 눈 쌍은 변경 사항의 작성자와 함께 코드 변경 사항을 검토합니다. 검토자는 변경 사항을 검토하여 변경 사항을 이해하고 테스트에 충분히 포함되도록합니다. 검토 과정은 수동이며 그러나 테스트 (단위 및 통합 테스트 및 사용자 승인 테스트)가이 수동 검토 프로세스를 통과하면 자동 빌드 프로세스의 일부가됩니다. 변경 사항이 체크인 될 때마다 실행됩니다. A지속적인 통합 서버는 빌드 프로세스의 일부로이 작업을 수행합니다.

자동으로 실행되는 테스트는 코드 동작의 무결성을 유지하며 향후 코드베이스 변경으로 인해 코드 가 손상 되는 것을 방지합니다 .

마지막으로, 테스트를 제공하면 변경 사항이 기존 테스트를 중단하지 않는다는 점에서 큰 코드를 안전하게 개선 할 수 있으므로 코드 를 적극적으로 리팩터링 할 수 있습니다.

테스트 주도 개발에 대한주의 사항이 있으며 테스트 가능하게 만들기 위해 코드를 작성해야한다는 것입니다. 인터페이스에 코딩하고 협업 객체를 인스턴스화하기 위해 Dependency Injection과 같은 기술을 사용합니다. TDD를 잘 설명 하는 Kent Beck 의 작품을 확인하십시오 . 조회 인터페이스를 코딩 및 연구디자인 패턴

답변

import org.junit.runner.RunWith;
import org.junit.runners.Suite;
import org.junit.runners.Suite.SuiteClasses;

@RunWith(Suite.class)
@SuiteClasses({ MyClassTest.class, MySecondClassTest.class })
public class AllTests { }