파일 리더를 어떻게 테스트합니까?

몇 가지 파일 형식으로 프로젝트를 진행 중입니다. 일부 형식은 .xsds로 지정되고 다른 형식은 해당 웹 사이트의 문서로 지정되며 일부는 문서가없는 사용자 지정 사내 형식입니다. 음하 하하하

뭐가 문제 야?

파일 리더를 테스트하고 싶지만이 작업을 수행하는 방법을 완전히 모르겠습니다. 응용 프로그램의 흐름은 다음과 같습니다.

file.___  ===> read by FileReader.java ===> which creates a Model object

FileReader인터페이스가 있는 곳

public interface FileReader {
    public Model read(String filename);
}

는 Model파일을 읽을 때 채워집니다 속성을 가지고 있습니다. 그것은 다음과 같습니다

public class Model {
    List<String> as;
    List<String> bs;
    boolean isAPain = true;
    // ...
}

내가 무엇을 시도 했습니까?

내 유일한 아이디어는 각 파일 형식에 대해 파일 "생성기"를 만드는 것입니다. 이 생성기는 기본적으로 몇 가지 변수 (예 : 파일에 생성 할 주석 수)를 사용하고 샘플 파일을 출력 한 다음 결과를 읽고 Model파일을 처음 생성 할 때 사용한 변수와 결과 를 비교하는 빌더입니다 .

그러나 몇 가지 문제가 있습니다.

• 그것이 생성하는 파일은 실제 파일처럼 보이지 않습니다 . 생성기는 컨텍스트를 전혀 인식하지 못합니다.
• 변수를 수동으로 설정 한 사람이기 때문에 생성기가 엣지 케이스를 생성했는지 여부를 인식하기가 어렵습니다. 이 방법은 수십 개의 샘플 파일을 만드는 것보다 낫습니다.

더 좋은 방법이 있습니까?

편집 : 실제로 의미하는대로 단위를 통합으로 변경했습니다.

EDIT2 : 여기에 내가 언급 한 엣지 케이스의 예가 있습니다.

각 파일은 꼭짓점과 가장자리로 구성된 그래프를 나타냅니다. 이 정점과 모서리는 다른 방식으로 부착 될 수 있습니다.

v1 -- e1 --> v2 <-- e2 -- v3

~와 다르다

v1 -- e1 --> v2 -- e2 --> v3

가장자리의 방향이 중요합니다. 이것이 질문의 범위에 있는지 확실하지 않지만 수동으로 정점 수, 모서리 수를 설정하고 무작위로 연결을 생성 할 때 모든 관련 모서리 사례를 생각하기가 어렵습니다.

먼저, 당신의 목표가 무엇인지에 대해 이야기 해 봅시다 :

• "파일 형식"을 테스트하고 싶지는 않습니다. 다른 FileReader구현 을 테스트하고 싶습니다.

• 자동 테스트를 통해 가능한 많은 유형의 오류를 찾고 싶습니다.

이 목표를 완전히 달성하기 위해 IMHO는 다른 전략을 결합해야합니다.

• 첫째, 실제 단위 테스트 : FileReader구현은 다양한 부분과 기능으로 구성됩니다. 각 테스트를 개별적으로 테스트하는 작은 테스트를 작성하십시오. 실제로 파일에서 데이터를 읽을 필요가없는 방식으로 함수를 설계하십시오. 이러한 종류의 테스트는 대부분의 문제를 테스트하는 데 도움이됩니다.
• 둘째, 생성 된 파일 :이 파일을 통합 테스트라고합니다. 이러한 파일을 사용하면 특정 매개 변수 조합, 파일 액세스 오류 등과 같은 지점 1과 다른 오류를 추적하는 데 도움이됩니다. 좋은 테스트 사례를 만들려면 테스트 사례를 동등성 클래스 또는 경계 값 테스트. 글렌 포드 마이어스 (Glenford Myers) 가 저술 한이 책 의 사본을 얻으십시오 . 소프트웨어 테스트에 대한 Wikipedia 기사 도 좋은 자원이다.
• 셋째, 실제 데이터를 얻으십시오.이 파일이 귀하 FileReader의 파일에 의해 올바르게 평가되는지 확인하기가 어려울 수 있지만 처음 두 가지 전략으로 밝혀지지 않은 버그를 발견하기 때문에이 작업을 수행하는 것이 좋습니다. 어떤 사람들은 이런 종류의 것들을 "통합 테스트"라고 부르고 어떤 사람들은 "허용 테스트"를 선호하지만 실제로 그 용어는 중요하지 않습니다.

IMHO는 "단일"접근 방식이 없기 때문에 "하나의 가격으로"세 가지 전략의 이점을 모두 누릴 수 있습니다. 실제 사례뿐만 아니라 표준 사례의 실패뿐만 아니라 엣지 사례를 탐지하려면 최소한 많은 노력을 기울여야합니다. 운 좋게도 이러한 모든 접근 방식을 사용하여 자동 반복 테스트를 작성할 수 있습니다.

그 외에도 FileReader데이터를 읽을 때 오류를 가리지 않아야합니다. 내장 검사 / 어설 션을 만들고 내부에서 문제가 발생할 때 예외를 던지는 등 테스트 코드가 오류를 훨씬 더 잘 감지 할 수 있습니다. 예상치 못한 상황에 대한 명시적인 테스트 파일이나 테스트 사례가없는 경우에도 마찬가지입니다.