5
단위 테스트에 가장 적합한 방법으로는 컴파일러와 같은 복잡한 단위가 있습니까?단위 테스트 컴파일러
필자는 지난 몇 년 동안 컴파일러와 인터프리터를 작성 했으므로 이런 종류의 코드는 좋은 방법으로 테스트하기가 어렵습니다.
우리는 추상 구문 트리 생성과 같은 것을 사용합니다. TDD를 사용하여 어떻게 테스트합니까?
작은 구조는 테스트하기 쉽습니다. 예 :
string code = @"public class Foo {}";
AST ast = compiler.Parse(code);
이렇게하면 노드가 많이 생성되지 않습니다.
하지만 실제로 컴파일러는 방법 같은 것을위한 AST를 생성 할 수 있는지 테스트하려면 :
[TestMethod]
public void Can_parse_integer_instance_method_in_class()
{
string code = @"public class Foo { public int method(){ return 0;}}";
AST ast = compiler.Parse(code);
당신은 무엇에 주장하는 것입니까? 주어진 코드를 나타내는 AST를 수동으로 정의하고 생성 된 AST가 수동으로 정의 된 AST를 준수한다는 주장을 끔찍하게 혼란스럽게 만들고 오류가 발생할 수도 있습니다.
이렇게 복잡한 시나리오를 TDD로 처리하는 가장 좋은 방법은 무엇입니까?
단위 테스트가 쓸모없고 열등한 이유의 수많은 예 중 하나 일 뿐이며 통합 테스트에 초점을 맞추어야합니다. TDD는 심각한 문제가 아니라 CRUD를위한 것입니다. 컴파일러의 경우 무작위로 생성 된 코드 테스트가 최선의 방법입니다. 예 : http://www.cs.utah.edu/~regehr/papers/pldi11-preprint.pdf –
안전한 컴파일러 작성에 대한 더 나은 접근법에 관심이있을 수 있습니다. http://compcert.inria.fr/doc /index.html - 공식 사양은 가능한 모든 테스트보다 품질을 확실히 보장합니다. –
@peer, 무슨 "방법"을 말하는거야? 구문 분석기가 생성되면 ('bison'이라고 생각하면) 모 놀리 식 문법과 생성 된 코드 더미를 읽을 수 없습니다. 문법 전체를 테스트 할 필요가 없습니다. 필기체의 재귀 파서 인 경우 단위 테스트 (예 : Clang 소스 코드를보고 작은 파서 항목마다 ASTContext와 입력 스트림을 조롱하는 방법을 생각해보십시오.)하기가 더 어렵습니다. 합리적으로 복잡한 코드의 경우 유닛 테스트는 사실상 무의미합니다. –