인터프리터나 컴파일러를 테스트하려면 어떻게 해야 합니까?

StackOverflow https://stackoverflow.com/questions/691844

문제

나는 Brainfuck용 인터프리터를 만드는 실험을 해왔고, 만들고 실행하는 것이 매우 간단하지만 내 일부는 그것에 대해 테스트를 실행할 수 있기를 원합니다.구현이 올바른지 확인하기 위해 가능한 모든 명령 조합을 테스트하기 위해 얼마나 많은 테스트를 작성해야 하는지 짐작할 수 없습니다.

분명히 Brainfuck의 명령어 세트는 작지만 더 많은 명령어가 추가될수록 테스트 코드가 기하급수적으로 늘어날 것이라고 생각하지 않을 수 없습니다.어쨌든 일반적인 테스트보다 더 그렇습니다.

이제 저는 컴파일러와 인터프리터 작성 측면에서 거의 초보자이므로 제 가정은 기본에서 크게 벗어날 수 있습니다.

기본적으로 이와 같은 테스트는 어디서부터 시작합니까?

도움이 되었습니까?

해결책

컴파일러 테스트는 다른 종류의 앱 테스트와 약간 다릅니다. 왜냐하면 컴파일러가 모두 올바른 작업을 수행하는 한 컴파일러가 프로그램의 다양한 어셈블리 코드 버전을 생성해도 괜찮기 때문입니다.그러나 단지 인터프리터를 테스트하는 경우에는 다른 텍스트 기반 애플리케이션과 거의 동일합니다.다음은 Unix 중심 보기입니다.

  1. 당신은 구축하고 싶을 것입니다 회귀 테스트 스위트.각 테스트에는
    • 당신이 해석할 소스 코드 test001.bf
    • 해석할 프로그램에 대한 표준 입력은 다음과 같습니다. test001.0
    • 통역사가 표준 출력에서 ​​생성하기를 기대하는 것 test001.1
    • 통역사가 표준 오류에 대해 생성할 것으로 기대하는 것 test001.2 (통역사의 오류 메시지를 테스트하고 싶기 때문에 표준 오류에 관심이 있습니다)

  2. 다음과 같은 작업을 수행하는 "테스트 실행" 스크립트가 필요합니다.

    function fail {
  echo "Unexpected differences on $1:"
  diff $2 $3
  exit 1
}

for testname
do
  tmp1=$(tempfile)
  tmp2=$(tempfile)
  brainfuck $testname.bf < $testname.0 > $tmp1 2> $tmp2
  [ cmp -s $testname.1 $tmp1 ] || fail "stdout" $testname.1 $tmp1
  [ cmp -s $testname.2 $tmp2 ] || fail "stderr" $testname.2 $tmp2
done

  3. 다음과 같은 작업을 수행하는 "테스트 생성" 스크립트를 갖는 것이 도움이 될 것입니다.

    brainfuck $testname.bf < $testname.0 > $testname.1 2> $testname.2

    통역사가 해당 사례에 적합하다고 완전히 확신하는 경우에만 이 작업을 실행합니다.

  4. 테스트 스위트를 소스 제어하에 유지합니다.

  5. 비어 있을 것으로 예상되는 파일을 제외할 수 있도록 테스트 스크립트를 장식하는 것이 편리합니다.

  6. 변경사항이 있을 때마다 모든 테스트를 다시 실행합니다.크론 작업을 통해 밤새도록 다시 실행할 수도 있습니다.

  7. 마지막으로, 좋은 결과를 얻기 위해 충분한 테스트를 추가하고 싶습니다. 테스트 커버리지 컴파일러의 소스 코드.적용 범위 도구의 품질은 매우 다양하지만 GNU Gcov 적절한 적용 범위 도구입니다.

통역사에게 행운을 빕니다!사랑스럽게 제작되었지만 잘 문서화되지 않은 테스트 인프라를 보려면 다음을 살펴보십시오. test2 디렉토리 빠른 C-- 컴파일러.

다른 팁

컴파일러 테스트에 대해 '특별한'것이 있다고 생각하지 않습니다. 어떤 의미에서는 일부 프로그램을 테스트하는 것보다 거의 더 쉽습니다. 컴파일러는 기본적인 고급 요약을 가지고 있기 때문에 소스에 손을 대고 컴파일 된 코드와 (아마도) 일련의 진단 메시지를 제공합니다.

복잡한 소프트웨어 엔티티와 마찬가지로 많은 코드 경로가 있지만 데이터 지향적 인 매우 데이터 지향 (텍스트, 텍스트 및 바이트)이므로 저자 테스트에 간단합니다.

컴파일러 테스트에 관한 기사를 썼는데, 원래 결론은 다음과 같습니다. 바퀴를 재창조하는 것은 도덕적으로 잘못입니다. 기존 솔루션에 대해 이미 알고 있고이를 무시할 좋은 이유가 없다면, 이미 존재하는 도구를 살펴 보는 것으로 시작해야합니다. 시작하기 가장 쉬운 곳은입니다 gnu c 고문, 그러나, 그것은 우리가 말할 것이라는 Deja Gnu를 기반으로한다는 것을 명심하십시오. (관리자가 허용하는 데 6 번의 시도가 필요했습니다. 중요한 버그 보고서 메일 링리스트에 대한 Hello World 예제에 대해.)

나는 당신이 다음을 도구를 조사 할 수있는 출발점으로 보는 것을 무모하게 제안합니다.

  1. 소프트웨어 : 연습과 경험 2007 년 4 월. (일반 대중에게는 이용할 수 없음 --- 무료 사전 인쇄 http://pobox.com/~flash/practical_testing_of_c99.pdf.

  2. http://en.wikipedia.org/wiki/compiler_correctness#testing (주로 저에 의해 작성되었습니다.)

  3. 컴파일러 테스트 참고 문헌 (내가 놓친 업데이트를 알려주세요.)

Brainfuck의 경우 Brainfuck 스크립트로 테스트해야한다고 생각합니다. 그래도 다음을 테스트 할 것입니다.

1 : 모든 셀이 0으로 초기화됩니다

2 : 현재 첫 번째 셀을 가리킬 때 데이터 포인터를 줄이면 어떻게됩니까? 포장합니까? 유효하지 않은 메모리를 가리십니까?

3 : 마지막 셀을 가리킬 때 데이터 포인터를 증가시킬 때 어떻게됩니까? 포장합니까? 유효하지 않은 메모리를 가리 킵니다

4 : 출력 기능이 올바르게 작동합니다

5 : 입력 기능이 올바르게 작동합니다

6 : [] 물건이 올바르게 작동합니까?

7 : 바이트를 255 회 이상 증가시킬 때 어떻게되는지, 0으로 랩핑하거나 정수 또는 기타 값으로 잘못 처리됩니까?

더 많은 테스트도 가능하지만 아마도 내가 시작한 곳 일 것입니다. 몇 년 전에 BF 컴파일러를 썼는데 몇 가지 추가 테스트가있었습니다. 특히 코드 생성기의 초기 버전에는 문제가 있었기 때문에 (JXX를 사용하는 x86에서는 블록이 128 바이트 이상을 생성했을 때 문제가 있었기 때문에 특히 블록 내부에 많은 코드를 사용하여 [] 재료를 심하게 테스트했습니다. x86 ASM이 잘못된 코드, 결과).

이미 작성된 일부 앱으로 테스트 할 수 있습니다.

비밀은 다음과 같습니다.

  • 우려 사항을 분리하십시오
  • Demeter의 법칙을 관찰하십시오
  • 의존성을 주입하십시오

글쎄, 테스트하기 어려운 소프트웨어는 개발자가 1985 년처럼 썼다는 신호입니다. 죄송합니다. 그러나 내가 여기에 제시 한 세 가지 원칙을 사용하면 기본적으로 짝수가 단위 테스트 가능합니다 (종속성을 주입 할 수 있습니다. 기본, "GOTO 변수"를 수행 할 수 있기 때문입니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top