仅构建可执行文件的Haskell Cabal项目代码覆盖率报错咨询

我有一个仅构建可执行文件的Cabal项目，执行cabal test --enable-coverage命令时，9个测试全部通过，但出现如下报错：

All 9 tests passed (0.98s)
Test suite giter-test: PASS
Test suite logged to:
/home/refaelsh/repos/giter/dist-newstyle/build/x86_64-linux/ghc-9.2.7/giter-0.1.0/test/giter-0.1.0-giter-test.log
Error: .cabal-wrapped: Test coverage is only supported for packages with a
library component.

Error: cabal: Tests failed for giter-0.1.0.

1. 报错原因解释 #

Cabal的--enable-coverage测试覆盖率功能依赖GHC的覆盖率收集机制，而该机制仅支持为库组件生成覆盖率数据。你的项目只有可执行文件组件，没有库，Cabal无法完成覆盖率信息的收集工作，因此触发这个错误——即便测试本身全部通过，覆盖率收集失败也会被判定为整个测试流程失败。

2. 仅含可执行文件的项目出现此报错是否正常？ #

完全正常。这是Cabal与GHC的设计限制导致的，官方明确测试覆盖率功能仅针对包含库组件的项目，纯可执行项目启用该参数必然会触发此报错。

3. 是否应将待测试代码抽离为库组件，让可执行文件依赖该库？ #

是，建议进行这样的调整。

3a. 这是否符合Haskell的惯用开发实践？ #

绝对符合。Haskell社区的常规开发模式就是将核心业务逻辑、可复用代码放在库组件中，可执行文件仅作为入口层，负责解析命令行参数、调用库的核心函数等轻量化工作。这种结构不仅便于编写单元测试，还能提升代码的可复用性与模块化程度。

3b. 为适配单元测试修改代码或项目结构是否属于代码坏味道？ #

不属于。为提升可测试性调整项目结构，本质是优化代码的模块化水平，属于良好的工程实践。代码坏味道通常指为短期便利引入的冗余、高耦合或难以维护的代码，而拆分库组件是在优化代码架构，长期来看能降低维护成本、提升代码质量。

内容的提问来源于stack exchange，提问作者Refael Sheinker