将单元测试保存在D中的单独文件中

时间:2014-06-02 08:35:15

标签: unit-testing testing d

我想测试用D编写的代码。我正在使用DUB来构建项目(但到目前为止,配置是相当基本的:只是名称和dunit依赖项。)

我在很多项目中都看到单元测试放在实际代码旁边(例如http://wiki.dlang.org/Unittest#Placement)。

虽然这对小模块和简单测试来说是好的,但如果我真的想测试我的代码怎么办?

在Java(和其他JVM语言)中,惯例完全相反 - 将测试保存在单独的文件中(通常反映测试中的单元包装)。

是否可以在D?

中为单元测试设置单独的文件

我希望有一个经典的设置:

dub.json
/source/mylib/app.d
/tests/mylib/app_tests.d

将文件app_tests(与其他文件展开tests)与DUB集成 - 仅在--unittests等期间编译/运行。

3 个答案:

答案 0 :(得分:8)

我不了解惯例,但最近我遇到了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/中)。

这并不完美,我仍然没有全力以赴,但我的工作很简单。

其中一个问题是,单独的单元测试模块无法访问源中的私有元素(虽然可以访问包和公共文件)。

我不完全确定这个配置是否有一些我不知道的副作用。也许更有经验的人会验证这种方法。

答案 1 :(得分:6)

没有什么可以阻止你在另一个模块的一个文件测试代码中使用unittest块。您可以在unittest块中放置任何可以放入正常函数的块。但是,除非unittest块在要测试的模块中,否则您无法访问正在测试的模块的任何私有成员。访问修饰符的正常限制适用。

D社区中有些人不喜欢在接受测试的地方进行单元测试,并选择将测试放在单独的文件中,但D的单元测试设施我们的设计理念是,您可以将测试放在他们正在测试的功能旁边。当您忘记单元测试函数并更容易一起修改代码和测试时,这会更加明显。它是D的标准库所做的,而AFAIK,是大多数D程序员选择做的。恕我直言,它的维护方式要好得多,而且如果你认为它使模块太大,那么你或者你可能会让你的模块太大,或者你太挑剔了模块有多大。但很明显,它是主观的,您是否想要将测试放在与他们测试的模块相同的模块中,这取决于您。您必须记住,如果它们分开,那么他们就无法访问正在测试的模块的任何私有成员。

答案 2 :(得分:2)

请记住,Java没有模块(但是当项目Jigsaw最终被合并时,它将在Java 9中发生变化),也没有内置的单元测试。如果它的话,故事可能会有所不同。我们将unittests保持在与我们想要进行单元测试的代码相近的一些正当理由。最明显的一个是地方。您需要在test-package和Java类所在的常规包之间切换多少次才能分析您正在编写单元测试的方法? :)

要回答您的问题 - 我认为您没有理由不能在单独的模块中进行单元测试。试试吧,如果我是你,那就是我会做的。