2017-11-19 4 views
2

방금 ​​스택을 사용하여 Cabal을 사용하지 않았지만 테스트 스위트에 문제가 있습니다. 라이브러리 및 실행 파일은 정상적으로 작동하지만 stack test이 나에게 준다tasty-discover with stack runs 0 tests

hml-0.1.0.0: test (suite: HML-test) 
All 0 tests passed (0.00s) 

즉. 테스트는 실시하지 않았다. 캐럴과 함께 테스트를 직접 실행하면 제대로 작동합니다. tastytasty-discover을 사용하고 있습니다. hml.cabal 제품군에서 다음과 같습니다

{-# OPTIONS_GHC -F -pgmF tasty-discover -optF --tree-display #-} 

어떤 아이디어 : tasty-discover에 대한

test-suite HML-test 
    main-is:    Driver.hs 
    hs-source-dirs:  test 
    default-language: Haskell2010 
    ghc-options:   -Wall 
    other-modules:  HML.Types.Test.PosInt 
         (...etc...) 
    build-depends:  base >= 4.9 
         (... etc...) 

드라이버 테스트/Driver.hs은 다음과 같습니다?

는 편집 :

음모로 컴파일 나는 dist/build/HML-test에서 실행 HML-test 찾아 직접 실행하는 모든 테스트를 실행합니다.

스택을 사용하여 컴파일 할 때 나는 .stack-work/x86_64-linux/Cabal-1.24.2.0/build/HML-test에서 찾았고 직접 실행해도 여전히 0 개의 테스트가 실행됩니다. 25 :

stack - v test의 전체 출력

버전 1.5.1, 힘내 개정 600c1f01435a10d127938709556c1682ecfd694e (4861 커밋)의 x86_64에 hpack 2017년 11월 19일 0.17.1-12 [디버그] 점검 : 05.759671 /home/cabox/workspace/hml/stack.yaml @ (스택/Config.hs : 974 : 9) 2017-11-19 12 : 25 : 05.759980 : [디버그] 프로젝트 구성 파일로드 stack.yaml @ (Stack/Config.hs : 999 : 13) 2017-11-19 12 : 25 : 05.762372 : [debug] 디코딩 시도 중 /home/cabox/.stack/build-plan-cache/x86_64-linux/lts-9.13. cache @ (Data/Store/VersionTagged.hs : 72 : 5) 2017-11-19 12 : 25 : 05.788669 : [debug] 성공한 디코딩 /home/cabox/.stack/build-plan-cache/x86_64-linux/lts -9.13.c @ (데이터/저장소/VersionTagged.hs : 76 : 13) 2 017-11-19 12 : 25 : 05.789952 : [디버그] 프로세스 실행 :/sbin/ldconfig -p @ (시스템/프로세스/Read.hs : 306 : 3) 2017-11-19 12 : 25 : 05.796009 : [디버그 ] 프로세스가 완료되었습니다. [92m5ms [0m :/sbin/ldconfig -p @ (시스템/프로세스/Read.hs : 306 : 3) 2017-11-19 12 : 25 : 05.796327 : [디버그]/gcc -v @ (System/Process/Read.hs : 306 : 3) 2017-11-19 12 : 25 : 05.799566 : [디버그] 프로세스가 [92m3ms [0m :/usr/bin/gcc -v @ (System/Process/Read.hs : 306 : 3) 2017-11-19 12 : 25 : 05.799710 : [디버그] PIE 사용 @ (스택/Setup.hs : 583 : 17) 2017-11-19 12 : 25 : 05.799912 : [디버그] 'ldconfig -p'에서 공유 라이브러리 libtinfo.so.5를 발견했습니다. @ (Stack/Setup.hs : 559 : 29) 2017-11-19 12 : 25 : 05.800147 : [디버그] 공유 라이브러리를 찾지 못했습니다. libtinfo.so.6 @ (스택/Setup.hs : 573 : 38) 2017-11-19 12 : 25 : 05.800285 : [디버그] 공유 라이브러리 libncursesw.so.6 @ (스택/Setup.hs : 573)을 찾지 못했습니다. : 38) 2017-11-19 12 : 25 : 05.800375 : [디버그] 'ldconfig -p'출력에 공유 라이브러리 libgmp.so.10이 있음 @ (Stack/Setup.hs : 559 : 29) 2017-11-19 12 : 25 : 05.800478 : [debug] s을 찾지 못했습니다. hale 라이브러리 libgmp.so.3 @ (Stack/Setup.hs : 573 : 38) 2017-11-19 12 : 25 : 05.800560 : [debug] 표준 GHC 빌드 사용 @ (Stack/Setup.hs : 606 : 9) 2017 -11-19 12 : 25 : 05.801346 : [디버그] 해당 버전 @ (스택/설치/Installed.hs : 103 : 13)에 대한 GHC 요청 2017-11-19 12 : 25 : 05.801592 : [디버그] 프로세스 실행 :/(시스템/프로세스/Read.hs : 306 : 3) 2017-11-19 12:25 :/home/cabox/05:802203 : [디버그] Cabal 패키지 버전 받기 (스택/GhcPkg.hs : 189 : 5) 2017-11-19 12 : 25 : 05.802507 : [디버그] 전역 패키지 데이터베이스 위치 얻기 @ (Stack/GhcPkg.hs : 55 : 5) 2017-11-19 12 : 25 : 05.808193 : [디버그] 프로세스 실행 : /home/cabox/.stack/programs/x86_64-linux/ghc-8.0.2/bin/ghc-pkg --no-user- package-db field --simple-output Cabal 버전 @ (System/Process/Read.hs : 306 : 3) 2017-11-19 12 : 25 : 05.808687 : [디버그] 프로세스 실행 : /home/cabox/.stack/ 프로그램/x86_64-linux/ghc-8.0.2/bin/ghc-pkg --no-user-package-db list --global @ (시스템/프로세스/Read.hs : 306 : 3) 2017-11-19 12 : 25 : 05.855073 : [디버그] 프로세스는 [92m46ms [0m : /home/cabox/.stack/programs/x86_64-linux/ghc-8.0]에서 완료되었습니다.2 - bin/ghc-pkg --no-user-package-db list --global @ (시스템/프로세스/Read.hs : 306 : 3) 2017-11-19 12 : 25 : 05.857161 : [디버그] 프로세스가 완료되었습니다. in [92m48ms [0m : /home/cabox/.stack/programs/x86_64-linux/ghc-8.0.2/bin/ghc-pkg --no-user-package-db 필드 - 간단한 출력 Cabal 버전 @ System/Process/Read.hs : 306 : 3) 2017-11-19 12 : 25 : 05.869048 : [디버그] 프로세스가 [92m67ms [0m : /home/cabox/.stack/programs/x86_64-linux/ghc- 8.0.2/bin/ghc --numeric-version @ (System/Process/Read.hs : 306 : 3) 2017-11-19 12 : 25 : 05.871256 : [디버그] 패키지 항목 해결 @ (Stack/Setup.hs : 260 : 5) 2017-11-19 12 : 25 : 05.897711 : [디버그] EnvConfig @ (Stack/Runners.hs : 175 : 18)에서 명령을 실행하기 시작 함 2017-11-19 12 : 25 : 05.897916 : [debug ] 로컬 패키지의 Cabal 파일 구문 분석 @ (Stack/Build/Source.hs : 328 : 5) 2017-11-19 12 : 25 : 05.905436 : [디버그] 대상 파싱 @ (Stack/Build/Source.hs : 265 : 5) 2017-11-19 12 : 25 : 05.917919 : [디버그] 시작 : getPackageFiles /home/cabox/workspace/hml/hml.cabal @ (Stack/Package.hs : 259 : 21) 2017 -11-19 12 : 25 : 06.009229 : 91ms에서 완료 : [디버그] getPackageFiles /home/cabox/workspace/hml/hml.cabal @ (Stack/Package.hs : 259 : 21) 2017-11-19 12:25 : 06.010508 : [디버그] 이미 설치되어있는 패키지 찾기 @ (스택/빌드/Installed.hs : 69 : 5) 2017-11-19 12 : 25 : 06.010877 : [디버그] 프로세스 실행 :/home/cabox /. 스택/프로그램/x86_64-linux/ghc-8.0.2/bin/ghc-pkg --global --no-user-package-db 덤프 --expand-pkgroot @ (System/Process/Read.hs : 306 : 3) 2017-11-19 12 : 25 : 06.062451 : [디버그] [92m51ms에서 완료되었습니다. [0m : /home/cabox/.stack/programs/x86_64-linux/ghc-8.0.2/bin/ghc-pkg - 전역 --no-user-package-db 덤프 --expand-pkgroot @ (System/Process/Read.hs : 306 : 3) 2017-11-19 12 : 25 : 06.086280 : [debug] 원하는대로 패키지 haskeline을 무시합니다. 0.7.3.0 대신 0.7.4.0 버전 (스택/빌드/Installed.hs : 199 : 5) 2017-11-19 12 : 25 : 06.086478 : [디버그] 0.4 대신 0.4.1.0을 원하기 때문에 [terminfo] 패키지 terminfo가 무시됩니다. .0.2 @ (스택/빌드/Installed.hs : 199 : 5) 2017-11-19 12 : 25 : 06.086581 : [디버그] pac 무시 3000.2.1 @ (스택/빌드/Installed.hs : 199 : 5) 대신 3000.2.2 버전을 원해서 kage xhtml 2017-11-19 12 : 25 : 06.086945 : [디버그] 프로세스 실행 :/home/cabox/.stack/programs/x86_64-linux/ghc-8.0.2/bin/ghc-pkg --user --no-user-package-db --package-db /home/cabox/.stack/snapshots/x86_64-linux /lts-9.13/8.0.2/pkgdb dump --expand-pkgroot @ (System/Process/Read.hs : 306 : 3) 2017-11-19 12 : 25 : 06.209627 : [디버그] 프로세스가 [92m122ms [ 0m : /home/cabox/.stack/programs/x86_64-linux/ghc-8.0.2/bin/ghc-pkg --user --no-user-package-db --package-db/home/cabox /. stack/snapshots/x86_64-linux/lts-9.13/8.0.2/pkgdb dump --expand-pkgroot @ (System/Process/Read.hs : 306 : 3) 2017-11-19 12 : 25 : 06.210994 : [디버그 ] 프로세스를 실행하십시오 : /home/cabox/.stack/programs/x86_64-linux/ghc-8.0.2/bin/ghc-pkg --user --no-user-package-db --package-db/home/cabox /workspace/hml/.stack-work/install/x86_64-linux/lts-9.13/8.0.2/pkgdb dump --expand-pkgroot @ (System/Process/Read.hs : 306 : 3) 2017-11-19 12 : 25 : 06.255376 : [디버그] 프로세스가 완료되었습니다. [92m43ms [0m : /home/cabox/.stack/programs/x86_64-linux/ghc-8.0.2/bin/ghc-pkg --user --no-user-package-db --package-db/home/cablo/workspace/hml/.stack-work/install/x86_64-linux/lts-9.13/8.0.2/pkgdb dump --expand-pkgroot @ (시스템/프로세스/Read.hs : 306 : 3) 2017-11- 19 12 : 25 : 06.256147 : [디버그] 빌드 계획 작성 @ (스택/빌드/ConstructPlan.hs : 188 : 5) 2017-11-19 12 : 25 : 06.270612 : [디버그] 같은 이름을 가진 실행 파일 @ (Stack/Build.hs :210 : 5) 2017-11-19 12 : 25 : 06.271198 : [디버그] 빌드 계획 실행 @ (Stack/Build/Execute.hs : 478 : 5) 2017 -11-19 12 : 25 : 06.282278 : [디버그] 전역 패키지 데이터베이스 위치 얻기 @ (스택/GhcPkg.hs : 55 : 5) 2017-11-19 12 : 25 : 06.282498 : [디버그] 프로세스 실행 :/home/cabob/.stack/programs/x86_64-linux/ghc-8.0.2/bin/ghc-pkg --no-user-package-db 목록 - 전역 @ (시스템/프로세스/Read.hs : 306 : 3) 2017 -11-19 12 : 25 : 06.319127 : [디버그] 프로세스가 [92m36ms에서 끝났습니다 [0m : /home/cabox/.stack/programs/x86_64-linux/ghc-8.0.2/bin/ghc-pkg --no- 우리 (시스템/프로세스/Read.hs : 306 : 3) 2017-11-19 12 : 25 : 06.320228 : [info] hml-0.1.0.0 : test (suite : HML-test)) @ (스택/빌드/Execute.hs : 830 : 23) 2017-11-19 12 : 25 : 06.321702 : [디버그] 프로세스 만들기 : /home/cabox/workspace/hml/.stack-work/dist/x86_64- linux/Cabal-1.24.2.0/build/HML-test/HML-test @ (시스템/프로세스/Run.hs : 139 : 5) 2017-11-19 12 : 25 : 06.344988 : [정보] @ (스택/빌드 /Execute.hs:1587:52) 모든 공 테스트 (0.00s)

통과

EDIT2 : 내가 수동으로 tasty을 구성하는 경우 (예 : 사용하지 말고 tasty-discover) 작동합니다. 이것은, 그러나 많은 일 및 많은 상용구로 이끌어 낼 것입니다.

+1

나는 맛있는 것을 사용하지 않았습니다. 그러나'stack test'는'Hspec'으로 잘 작동합니다. 어쩌면'--verbose' 플래그로 테스트를하는 것이 도움이 될 수도 있습니다. – palik

+0

@palik'-v' 출력에는 힌트가 없다는 것을 알 수 있습니다. 나는 OP에 이것을 포함 시켰습니다. – jorgen

+1

문제를 재현 할 수있었습니다. 그러나'{- # OPTIONS_GHC -F -pgmF tasty-discover # -}'및'defaultMain'을 사용하지 않고 테스트를 실행하면 아무런 문제가 없습니다. 스택 테스트에서 출력은 "XYZ 컴파일"과 함께 나타납니다. XYZ는 발견 할 수없는 모듈입니다. – palik

답변

1

가장 가까운 해결책은 tasty-discover에서 tasty-th으로 이동하는 것입니다.

전체 자동 검색은 여전히 ​​작동하지 않지만 TemplateHaskell에서 $(testGroupGenerator)까지를 사용하면 최소한 테스트 횟수보다는 테스트 파일 수가 더 많습니다.