我想测试我用 D 编写的代码。我正在使用 DUB 来构建项目（但到目前为止配置相当基本：只有名称和 dunit 依赖项）。
我在许多项目中看到单元测试放在实际代码旁边（例如http://wiki.dlang.org/Unittest#Placement）。
虽然这对于小模块和简单测试来说在 IMO 上是可以的，但如果我真的想测试我的代码怎么办？
在 Java（和其他 JVM 语言）中，约定完全相反 - 将测试保存在单独的文件中（通常反映被测单元的打包）。
是否可以在 D 中为单元测试提供单独的文件？
我希望有一个经典的设置：
dub.json
/source/mylib/app.d
/tests/mylib/app_tests.d
将文件 app_tests（与 tests 下的其他文件一样）与 DUB 集成 - 仅在 --unittests 等期间编译/运行。
【问题讨论】：
标签： unit-testing testing d
我不知道约定，但我最近遇到了这样的 DUB 解决方案：
{
"name": "sample",
"description": "sample app",
"configurations": [
{
"name": "application",
"targetType": "executable",
},
{
"name": "unittest",
"targetType": "executable",
"targetPath" : "tests",
"buildOptions": ["unittests"],
"excludedSourceFiles": ["source/app.d"],
"sourcePaths": ["tests/"],
"importPaths": ["tests/"],
"dependencies": {
"dunit": ">=1.0.9"
}
}
]
}
我在DUB sources 中找到了这个想法。现在，如果您运行dub，则将构建应用程序，如果您运行dub test，则将运行单元测试（放置在tests/）。
这并不完美，我还没有解决所有问题，但可以满足我的简单需求。
其中一个问题是单独的单元测试模块无法访问源代码中的私有元素（尽管它们可以访问包和公共元素）。
我不完全确定此配置是否有一些我不知道的副作用。也许更有经验的人会验证这种方法。
【讨论】：
没有什么能阻止您在一个文件中包含来自另一个模块的测试代码 unittest 块。您可以将任何可以放入普通函数的 unittest 块中。但是，除非unittest 块在被测试的模块中，否则您将无法访问正在测试的模块的任何私有成员。访问修饰符的正常限制适用。
D 社区中的一些人不喜欢将他们的单元测试放在被测试的内容旁边，并选择将测试放在单独的文件中，但 D 的单元测试设施的设计理念是您将在他们正在测试的功能旁边进行测试。当您忘记对函数进行单元测试时，这会更加明显，并且可以更轻松地同时修改代码和测试。这是 D 的标准库所做的，而 AFAIK，这是大多数 D 程序员选择做的。恕我直言，以这种方式进行维护要好得多，如果您认为它使模块太大，那么您可能还是使模块太大，或者您对模块的大小过于挑剔。但显然，这是主观的，是否要将测试放在与他们正在测试的模块相同的模块中取决于您。您只需要记住，如果它们是分开的，那么它们就无法访问正在测试的模块的任何私有成员。
【讨论】：
请记住，Java 没有模块（但是当 Jigsaw 项目最终被合并时，Java 9 中会发生变化），也没有内置的单元测试。如果确实如此，故事可能会有所不同。我们将单元测试保持在我们想要单元测试的代码片段附近有几个正当的理由。最明显的一个是地方性。您必须在测试包和 Java 类所在的常规包之间切换多少次才能分析您正在为其编写单元测试的方法？ :)
回答您的问题 - 我看不出为什么您不能在单独的模块中进行单元测试。试一试，如果我是你，我会这样做。
【讨论】：
private 部分。当然，我不知道如何告诉没有最好记录的 DUB 去做我所描述的事情..