1P by neo 2달전 | favorite | 댓글 1개
  • 속성 기반 테스트는 30년 이내에 주류로 자리 잡은 드문 학술 연구의 예임.
  • "테스트를 작성하지 말고 생성하라"는 슬로건 아래 다양한 프로그래밍 언어 커뮤니티에서 지지를 얻음.
  • 원래 Haskell 라이브러리인 QuickCheck의 Wikipedia 페이지에는 다른 언어로 57개의 재구현이 나열되어 있음.

속성 기반 테스트 라이브러리 조사

  • 현재 가장 많이 사용되는 속성 기반 테스트 라이브러리들을 조사하여 15년 전(2009년)의 최첨단 기술과 비교함.
  • 대부분의 라이브러리가 가장 진보된 속성 기반 테스트 기능을 제공하지 않음.

왜 속성 기반 테스트 라이브러리가 이런 슬픈 상태에 있는가?

상태 기반 및 병렬 테스트는 순수 테스트만큼 유용하지 않음

  • 상태 기반 모델링은 훈련이 필요함.
  • 폐쇄 소스가 산업 채택을 돕는다는 주장.

상태 기반 모델링은 훈련이 필요함

  • 상태 기반 및 병렬 테스트는 일반적인 테스트와 다른 사고방식을 요구함.
  • 새로운 사용자에게 이러한 도구를 제공할 때 적절한 훈련이 필요함.

폐쇄 소스가 산업 채택을 돕는다는 주장

  • 오픈 소스가 작동하지 않았고, 폐쇄 소스 제품과 관련 서비스가 채택을 돕는다는 주장.

우리가 할 수 있는 일

  • 상태 기반 및 병렬 속성 기반 테스트의 짧은 오픈 소스 구현 제공.
  • 개발자 훈련을 덜 필요로 하도록 형식 사양 부분을 더 쉽게 만들기.

순수 속성 기반 테스트 요약

  • 새로운 함수나 기능을 테스트하는 것이 좋은 관행으로 간주됨.
  • 예를 들어, 연결 리스트 역순 함수 reverse를 작성한 경우 빈 리스트와 같은 몇 가지 리스트에 대해 테스트하는 것이 합리적임.
  • 무작위 입력을 생성하는 것이 속성 기반 테스트의 주요 기능임.
  • 무작위 입력이 코너 케이스를 결국 찾을 것이라는 아이디어.

상태 기반 속성 테스트

  • 상태 기반 구성 요소를 테스트할 때 동일한 입력이 동일한 출력을 제공하지 않음.
  • 상태 기반 테스트에서는 입력 시퀀스를 생성하여 시스템이 시간이 지남에 따라 어떻게 변하는지 테스트함.
  • 메모리 내 참조 구현(모형)을 사용하여 상태를 명시적으로 설명함.

예: 카운터

  • 글로벌 가변 변수를 사용하여 카운터를 구현.
  • 모델은 정수로 표현됨.
  • 테스트는 명령 시퀀스를 생성하고 실행하여 실제 출력과 모델 출력을 비교함.

병렬 속성 기반 테스트

  • 병렬 테스트는 상태 기반 테스트 모델을 재사용하여 경합 조건을 감지함.
  • 병렬 테스트는 순차 상태 머신 모델을 사용하여 선형화 가능성을 통해 병렬 테스트를 수행함.

결론 및 향후 작업

  • 속성 기반 테스트의 상태를 개선하기 위해 오픈 소스 구현을 제공하고 형식 사양을 더 쉽게 만드는 것이 필요함.

GN⁺의 의견

  • 이 글은 속성 기반 테스트의 역사와 현재 상태를 잘 설명하고 있음.
  • 상태 기반 및 병렬 테스트의 중요성을 강조하며, 오픈 소스 구현의 필요성을 제기함.
  • 속성 기반 테스트를 더 쉽게 접근할 수 있도록 하는 방법을 제안함.
  • 비슷한 기능을 가진 다른 프로젝트로는 Hypothesis(Python)와 PropEr(Erlang)이 있음.
  • 새로운 기술이나 오픈 소스를 채택할 때는 훈련과 지원이 필요함을 강조함.
Hacker News 의견
  • clojure.spec.alphatest.check를 사용한 경험이 좋았음
    • Python의 hypothesis는 큰 데이터 세트를 처리하지 못해 사용 중단함
  • Go 언어의 커버리지 기반 퍼징이 잘 지원됨
    • 퍼징 테스트와 불변성 검사를 통해 속성 테스트와 유사한 결과를 얻을 수 있음
  • 연구 논문이 오픈 소스 도구로 재현 가능해야 한다는 요구는 유용한 정보를 잃게 할 수 있음
  • Rust의 proptest를 사용해 상태 기반 속성 테스트를 자주 작성함
    • 병렬 테스트는 때때로 유용하지만, 여러 테스트를 병렬로 실행하는 것이 더 쉬울 수 있음
  • Quviq QuickCheck 논문을 읽었으나, 상태 기반 테스트를 직접 작성하는 것이 더 나을 수 있음
    • StateModel은 추가적인 프레임워크 코드가 필요해 효율적이지 않음
  • 상태 기계와 병렬 측면 외에도 커버리지 기반 속성 테스트가 더 큰 영향을 미칠 수 있음
    • 자동 축소 기능을 유지하면서 값 생성 시 모든 불변성을 유지하는 것이 중요함
    • Hypothesis의 "내부 축소" 접근 방식이 가장 효과적임
  • Clojure에도 상태 기반 QuickCheck 라이브러리가 있음
    • 병렬 테스트는 아직 큰 문제가 되지 않음
  • 속성 기반 테스트는 엄격한 테스트를 작성할 수 있는 경우 타입 시스템에 통합하는 것이 더 나음
    • 단순한 "스모크 테스트"는 임의의 입력을 사용하는 것이 더 쉬움
  • QuviQ Erlang QuickCheck의 무료 버전인 QuickCheck Mini도 있음
  • JavaScript에서 속성 기반 테스트 라이브러리를 사용해 특정 조건을 만족하지 않는 임의의 값을 생성할 수 있는지 궁금함