开发者

API sanity autotest help needed

开发者 https://www.devze.com 2022-12-25 04:13 出处:网络
I am trying to auto-generate Unit Tests for my C code using API sanity autotest. But, the problem is that it is somewhat complex to use, and some tutorials / howto / other resources on how to use it

I am trying to auto-generate Unit Tests for my C code using API sanity autotest.

But, the problem is that it is somewhat complex to use, and some tutorials / howto / other resources on how to use it would be really helpful.

Have you had any luck with A开发者_如何学PythonPI sanity autotest? Do you think there's a better tool that can be used to auto-generate unit tests for C code?


It is a better tool (among free solutions for Unix) to fully automatically generate smoke tests if your library contains more than hundred functions. The unique feature is an ability to automatically generate reasonable input arguments for each function.

The most popular use case of this framework is a quick search for memory problems (segfaults) in the library. Historically, this framework was used to create LSB certification test suites for too big libraries like Qt3 and Qt4 that cannot be created manually in reasonable time.

Use the following command to generate, build and execute tests:

api-sanity-checker -l name -d descriptor.xml -gen -build -run

XML descriptor is a simple XML file that specifies version number, paths to headers and shared objects:

<version>
    0.3.4
</version>

<headers>
    /usr/local/libssh/0.3.4/include/
</headers>

<libs>
    /usr/local/libssh/0.3.4/lib/
</libs>

You can improve generated tests using specialized types for input parameters.

See example of generated tests for freetype2 2.4.8.


It's a recipe for disaster in the first place. If you auto-generate unit tests, you're going to get a bunch of tests that don't mean a lot. If you have a library that is not covered in automated tests then, by definition, that library is legacy code. Consider following the conventional wisdom for legacy code...

For each change:

  1. Pin behavior with tests
  2. Refactor to the open-closed principle (harder to do with C but not impossible)
  3. Drive changes for new code with tests

Also consider picking up a copy of Working Effectively with Legacy Code.

EDIT:

As a result of our discussion, it has become clear that you only want to enforce some basic standards, such has how null pointer values are handled, with your generated tests. I would argue that you don't need generated tests. Instead you need a tool that inspects a library and exercises its functions dynamically, ensuring that it meets some coding standards you have defined. I'd recommend that you write this tool, yourself, so that it can take advantage of your knowledge of the rules you want enforced and the libraries that are being tested.

0

精彩评论

暂无评论...
验证码 换一张
取 消