如何为“make check”创建测试? 使用 GNU 自动工具

发布于 2024-07-05 21:55:06 字数 244 浏览 8 评论 0原文

我正在使用 GNU 自动工具来构建特定项目的系统。 我想开始编写自动化测试来进行验证。 我想只需输入“make check”即可让它自动运行这些。 我的项目是用 C++ 编写的,尽管我仍然对为其他语言编写自动化测试感到好奇。

这与几乎所有单元测试框架兼容吗(我正在考虑使用 cppunit)? 如何将这些单元测试框架挂接到 make check 中? 我能否确保不需要安装单元测试软件就能够配置和构建项目的其余部分?

I'm using GNU autotools for the build system on a particular project. I want to start writing automated tests for verifcation. I would like to just type "make check" to have it automatically run these. My project is in C++, although I am still curious about writing automated tests for other languages as well.

Is this compatible with pretty much every unit testing framework out there (I was thinking of using cppunit)? How do I hook these unit testing frameworks into make check? Can I make sure that I don't require the unit test software to be installed to be able to configure and build the rest of the project?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

兰花执着 2024-07-12 21:55:07

要在发出 make check 时运行测试,您需要将它们添加到 TESTS 变量中

假设您已经构建了运行单元测试的可执行文件,只需添加将可执行文件的名称添加到 TESTS 变量,如下所示:

TESTS=my-test-executable

当您进行检查时,它应该自动运行,如果可执行文件返回非零值,它将报告为测试失败。 如果您有多个单元测试可执行文件,只需将它们全部列在 TESTS 变量中:

TESTS=my-first-test my-second-test my-third-test

它们就会全部运行。

To make test run when you issue make check, you need to add them to the TESTS variable

Assuming you've already built the executable that runs the unit tests, you just add the name of the executable to the TESTS variable like this:

TESTS=my-test-executable

It should then be automatically run when you make check, and if the executable returns a non-zero value, it will report that as a test failure. If you have multiple unit test executables, just list them all in the TESTS variable:

TESTS=my-first-test my-second-test my-third-test

and they will all get run.

痞味浪人 2024-07-12 21:55:07

我正在使用 Check 0.9.10

    configure.ac
    Makefile.am
    src/Makefile.am
    src/foo.c
    tests/check_foo.c
    tests/Makefile.am
  1. ./configure.ac

    PKG_CHECK_MODULES([CHECK], [检查 >= 0.9.10])

  2. ./tests/Makefile.am 用于测试代码

    测试 = check_foo 
      check_PROGRAMS = check_foo 
      check_foo_SOURCES = check_foo.c $(top_builddir)/src/foo.h 
      check_foo_CFLAGS = @CHECK_CFLAGS@ 
      
  3. 并编写测试代码,./tests/check_foo.c

    <前><代码>START_TEST (test_foo)
    {
    ck_assert( foo() == 0 );
    ck_assert_int_eq( foo(), 0);
    }
    END_测试

    /// 并且有一些 tcase_xxx 代码来运行这个测试

使用 check 您可以使用超时并引发信号。 这很有帮助。

I'm using Check 0.9.10

    configure.ac
    Makefile.am
    src/Makefile.am
    src/foo.c
    tests/check_foo.c
    tests/Makefile.am
  1. ./configure.ac

    PKG_CHECK_MODULES([CHECK], [check >= 0.9.10])

  2. ./tests/Makefile.am for test codes

    TESTS = check_foo
    check_PROGRAMS = check_foo
    check_foo_SOURCES = check_foo.c $(top_builddir)/src/foo.h
    check_foo_CFLAGS = @CHECK_CFLAGS@
    
  3. and write test code, ./tests/check_foo.c

    START_TEST (test_foo)
    {
        ck_assert( foo() == 0 );
        ck_assert_int_eq( foo(), 0);
    }
    END_TEST
    
    /// And there are some tcase_xxx codes to run this test
    

Using check you can use timeout and raise signal. it is very helpful.

红墙和绿瓦 2024-07-12 21:55:07

您似乎在第一段中问了两个问题。

第一个是关于向 GNU autotools 工具链添加测试 - 但如果我理解正确的话,这些测试是为了验证构建应用程序所需的环境是否存在(依赖库和工具)以及使构建适应环境(平台特定差异)。

第二个是关于对 C++ 应用程序进行单元测试以及在何处调用这些测试,您建议从 autotools 工具链(可能是从配置脚本)执行此操作。 不过,这样做并不传统 - 在 Makefile 中放入“测试”目标是执行测试套件的更传统方法。 使用自动工具构建和安装应用程序的典型步骤(至少从用户的角度来看,而不是从您(开发人员的角度))是运行配置脚本,然后运行 ​​make,然后可选地运行 make test,最后运行 make install。

对于第二个问题,不希望 cppunit 成为依赖项,为什么不将其与您的 C++ 应用程序一起分发呢? 您能否将其与源代码一起以您正在使用的任何存档格式(无论是 tar.gz、tar.bz2 或 .zip)正确放置。 我过去使用过 cppunit,并且对它很满意,因为我使用过 JUnit 和其他 xUnit 风格的框架。

You seem to be asking 2 questions in the first paragraph.

The first is about adding tests to the GNU autotools toolchain - but those tests, if I'm understanding you correctly, are for both validating that the environment necessary to build your application exists (dependent libraries and tools) as well as adapt the build to the environment (platform specific differences).

The second is about unit testing your C++ application and where to invoke those tests, you've proposed doing so from the autotools tool chain, presumably from the configure script. Doing that isn't conventional though - putting a 'test' target in your Makefile is a more conventional way of executing your test suite. The typical steps for building and installing an application with autotools (at least from a user's perspective, not from your, the developer, perspective) is to run the configure script, then run make, then optionally run make test and finally make install.

For the second issue, not wanting cppunit to be a dependency, why not just distribute it with your c++ application? Can you just put it right in what ever archive format you're using (be it tar.gz, tar.bz2 or .zip) along with your source code. I've used cppunit in the past and was happy with it, having used JUnit and other xUnit style frameworks.

也只是曾经 2024-07-12 21:55:07

您可以使用 Automake 的 TESTS 来运行由 check_PROGRAMS 生成的程序,但这将假定您正在使用日志驱动程序和编译器来输出。 仍然使用 check_PROGRAMS 可能更容易,但使用 Makefile 中的本地规则调用测试套件:

check_PROGRAMS=testsuite

testsuite_SOURCES=...
testsuite_CFLAGS=...
testsuite_LDADD=...

check-local:
    ./testsuite

You can use Automake's TESTS to run programs generated with check_PROGRAMS but this will assume that you are using a log driver and a compiler for the output. It is probably easier to still use check_PROGRAMS but to invoke the test suite using a local rule in the Makefile:

check_PROGRAMS=testsuite

testsuite_SOURCES=...
testsuite_CFLAGS=...
testsuite_LDADD=...

check-local:
    ./testsuite
若水般的淡然安静女子 2024-07-12 21:55:07

这是一个没有依赖项的方法:

#src/Makefile.am
check_PROGRAMS = test1 test2
test1_SOURCES = test/test1.c code_needed_to_test1.h code_needed_to_test1.c
test2_SOURCES = test/test2.c code_needed_to_test2.h code_needed_to_test2.c
TESTS = $(check_PROGRAMS)

make check 会自然地工作并显示格式化和汇总的输出:

$ make check
...
PASS: test1
PASS: test2
============================================================================
Testsuite summary for foo 1.0
============================================================================
# TOTAL: 2
# PASS:  2
# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0
============================================================================
  1. 当您执行 make dist 时, src/test/* 中不会显示任何内容 将是
    在压缩包中。 测试代码不在 dist 中,只有源代码会在。
  2. 当您执行 make distcheck 时,它将运行 make check 并运行您的测试。

Here is a method without dependencies:

#src/Makefile.am
check_PROGRAMS = test1 test2
test1_SOURCES = test/test1.c code_needed_to_test1.h code_needed_to_test1.c
test2_SOURCES = test/test2.c code_needed_to_test2.h code_needed_to_test2.c
TESTS = $(check_PROGRAMS)

The make check will naturally work and show formatted and summarized output:

$ make check
...
PASS: test1
PASS: test2
============================================================================
Testsuite summary for foo 1.0
============================================================================
# TOTAL: 2
# PASS:  2
# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0
============================================================================
  1. When you do a make dist nothing from src/test/* will be
    in the tarball. Test code is not in the dist, only source will be.
  2. When you do a make distcheck it will run make check and run your tests.
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文