모든 의존성을 가지고 테스트하는 것은 여전히 ​​중요하지만 Jeffrey Faust가 말한 것처럼 통합 테스트 영역에 있습니다.

단위 테스트의 가장 중요한 측면 중 하나는 테스트를 신뢰할 수있게 만드는 것입니다. 통과 테스트가 실제로 문제가 없다는 것을 의미하지 않고 테스트 실패가 실제로 프로덕션 코드의 문제를 의미한다고 믿을 수 없다면 테스트는 그다지 유용하지 않습니다.

테스트를 신뢰할 수있게하려면 몇 가지 작업을 수행해야하지만이 답변에 대해 하나만 집중하겠습니다. 코드를 체크인하기 전에 모든 개발자가 쉽게 실행할 수 있도록 실행하기 쉬운 지 확인해야합니다. “쉽게 실행”은 테스트가 빠르게 실행 되고 테스트를 신속하게 수행 할 수 있도록 구성 또는 설정이 필요하지 않음을 의미합니다 . 이상적으로는 누구나 최신 버전의 코드를 확인하고 테스트를 즉시 실행하여 통과하는 것을 볼 수 있어야합니다.

다른 것 (파일 시스템, 데이터베이스, 웹 서비스 등)에 대한 의존성을 제거하면 구성이 필요하지 않으며, “아, 내가 실패했기 때문에 테스트에 실패했습니다. 네트워크 공유가 설정되어 있지 않습니다. 아, 나중에 실행하겠습니다. ”

일부 데이터로 수행 한 작업을 테스트하려는 경우 해당 비즈니스 로직 코드에 대한 단위 테스트는 해당 데이터를 얻는 방법에 신경 쓰지 않아야 합니다. 데이터베이스와 같은 지원 항목에 의존하지 않고 응용 프로그램의 핵심 논리를 테스트 할 수 있다는 것은 대단합니다. 하지 않으면 빠진 것입니다.

추신 : 나는 테스트 가능성이라는 이름으로 과도하게 엔지니어링 할 수 있다고 덧붙여 야합니다. 애플리케이션을 시험 구동하면이를 완화 할 수 있습니다. 그러나 어쨌든 접근 방식의 구현이 잘못되어 접근 방식의 유효성이 떨어지지는 않습니다. “내가 왜 이러는 걸까?”라는 질문을 계속하지 않으면 어떤 것도 잘못 사용하고 지나칠 수 있습니다. 개발하는 동안.

내부 의존성에 관한 한, 상황이 약간 어둡습니다. 내가 생각하고 싶은 방식은 내가 틀린 이유로 수업을 가능한 한 많이 바꾸지 않기를 원한다는 것입니다. 이와 같은 설정이 있으면 …

public class MyClass
{
    private SomeClass someClass;
    public MyClass()
    {
        someClass = new SomeClass();
    }

    // use someClass in some way
}

나는 일반적으로 어떻게 SomeClass만들어 지는 상관하지 않습니다 . 그냥 사용하고 싶습니다. SomeClass가 변경되어 생성자에 매개 변수가 필요한 경우 내 문제가 아닙니다. 이를 수용하기 위해 MyClass를 변경할 필요는 없습니다.

이제는 디자인 부분 만 다루고 있습니다. 단위 테스트에 관한 한, 나는 또한 다른 수업으로부터 자신을 보호하고 싶습니다. MyClass를 테스트하는 경우 외부 종속성이 없으며 SomeClass가 데이터베이스 연결이나 다른 외부 링크를 도입하지 않았다는 사실을 알고 싶습니다.

그러나 더 큰 문제는 내 메소드의 일부 결과가 SomeClass의 일부 메소드의 출력에 의존한다는 것도 알고 있다는 것입니다. SomeClass를 조롱 / 스터 빙하지 않으면 요구에 따라 입력을 변경할 수있는 방법이 없을 수 있습니다. 운이 좋으면 SomeClass의 올바른 응답을 트리거하는 방식으로 테스트 내 환경을 작성할 수 있지만 그렇게하면 테스트에 복잡성이 생겨 부서지기 쉽습니다.

생성자에서 SomeClass의 인스턴스를 허용하도록 MyClass를 다시 작성하면 (모의 프레임 워크 또는 수동 모의를 통해) 원하는 값을 반환하는 SomeClass의 가짜 인스턴스를 만들 수 있습니다. 나는 일반적으로하지 않습니다 이 이 경우에 인터페이스를 소개합니다. 그렇게 할 것인지 아닌지는 여러 가지면에서 여러분이 선택한 언어에 의해 지시 될 수있는 개인적인 선택입니다 (예를 들어 C #에서는 인터페이스가 더 많지만 루비에서는 반드시 필요하지 않습니다).

답변