升压测试应用程序初始化

发布于 2024-08-16 16:19:36 字数 172 浏览 14 评论 0原文

我只是对新应用程序进行升压测试和单元测试,我不确定如何处理应用程序初始化(例如加载配置文件、连接到数据库、启动嵌入式 python 解释器等) 。

我想测试这个初始化过程,并且应用程序中的大多数其他模块也要求初始化成功发生。

运行一些关闭代码的某种方式也将受到赞赏。

我该怎么做呢?

I'm just getting stated with boost-test and unit testing in general with a new application, and I am not sure how to handle the applications initialisation (eg loading config files, connecting to a database, starting an embedded python interpretor, etc).

I want to test this initialisation process, and also most of the other modules in the application require that the initialisation occurred successfully.

Some way to run some shut down code would also be appreciated.

How should I go about doing this?

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

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

发布评论

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

评论(2

彡翼 2024-08-23 16:19:37

看来您想做的是更多的集成测试而不是单元测试。这并不是要精确指出措辞,但它会产生影响。单元测试意味着孤立的测试方法,在称为固定装置的环境中,仅为一个测试创建,结束然后删除。如果下一个案例需要相同的固定装置,则将重新创建固定装置的另一个实例。这样做是为了隔离测试,以便一个测试中的错误不会影响后续测试的结果。

通常,一个测试分为三个步骤:

  • 安排 - 准备夹具:实例化要测试的类,可能还需要其他对象
  • 行动 - 调用要测试的方法
  • 断言 - 验证期望

单元测试通常远离外部资源,例如文件和数据库。相反,模拟对象用于满足要测试的类的依赖关系。

但是,根据应用程序的类型,您可以尝试从应用程序本身运行测试。这不是“纯粹的”单元测试,但无论如何都是有价值的,特别是如果代码编写时没有考虑到单元测试,它可能不够“灵活”,无法进行单元测试。

这需要一种特殊的执行模式,例如使用“-test”参数,该模式将正常初始化应用程序,然后调用测试来模拟输入并使用断言来验证应用程序是否按预期做出反应。同样,可以调用关闭代码并使用断言验证数据库连接是否已关闭(如果对象未删除)。

与单元测试相比,这种方法有几个缺点:它取决于配置文件(软件的行为可能会根据参数而有所不同)、数据库(取决于其内容和连接到数据库的能力)、测试不是孤立的...前两个可以使用配置的默认值并在测试模式下连接到测试数据库来克服。

It seems what you intent to do is more integration test than unit-test. It's not to pinpoint on wording, but it makes a difference. Unit testing mean testing methods in isolation, in an environment called a fixture, created just for one test, end then deleted. Another instance of the fixture will be re-created if the next case require the same fixture. This is done to isolate the tests so that an error in one test does not affect the outcome of the subsequent tests.

Usually, one test has three steps:

  • Arrange - prepare the fixture : instantiate the class to be tested, possibly other objects needed
  • Act - call the method to be tested
  • Assert - verify the expectations

Unit tests typically stays away of external resources such as files and databases. Instead mock objects are used to satisfy the dependencies of the class to be tested.

However, depending on the type of your application, you can try to run tests from the application itself. This is not "pure" unit testing, but can be valuable anyway, especially if the code has not been written with unit testing in mind, it might not be "flexible" enough to be unit tested.

This need a special execution mode, with a "-test" parameter for instance, which will initialize the application normally, and then invoke tests that will simulate inputs and use assertions to verify the application reacted as expected. Likewise, it might be possible to invoke the shutdown code and verify with assertions if the database connection has be closed (if the objects are not deleted).

This approach has several drawbacks compared to unit tests: it depends on the config files (the software may behave differently depending on the parameters), on the database (on its content and on the ability to connect to it), the tests are not isolated ... The two first can be overcome using default values for the configuration and connecting to a test database in test mode.

擦肩而过的背影 2024-08-23 16:19:37

您正在定义 BOOST_TEST_MAIN 吗?如果是这样,并且您没有自己的 main 函数(否则您将在其中放置初始化代码),您可以使用某种形式的单例对象,该对象公开一个 init 函数,您可以在每次测试之前调用该函数必需的。

Are you defining BOOST_TEST_MAIN? If so, and you have no main function of your own (where you would otherwise put initialization code) you could feasibly use some form of singleton object that exposes an init function that you can call before each test if required.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文