集成测试-是否可以正确进行?

您所描述的实际上是集成测试(或多或少)。不,它不是反模式,而是软件开发生命周期的一个必要部分。

.

原因有几个方面:

• 单元测试是在一个孤立的环境中执行的,因此它们不能说明程序的各个部分在现实生活中是如何协同工作的
• “单元测试帽”很容易限制一个人的观点,所以有一整类的因素,开发人员根本不认为是需要测试的东西*
• 即使他们这样做了,也有一些事情无法在单元测试中进行合理的测试-例如,如何测试应用程序服务器是否在高负载下生存,或者数据库连接是否在请求过程中中断?

我刚刚从Luke Hohmann的书Beyond Software Architecture中读到一个例子:在一个应用程序中,通过创建和维护实际机器中硬件组件ID的“快照”,应用了强大的反盗版防御,开发人员用单元测试很好地覆盖了代码。随后,QA在一台没有网卡的机器上试用,成功在10分钟内使该应用崩溃。事实证明,由于开发人员正在开发Macs,他们理所当然地认为这台机器有一张网卡,其MAC地址可以合并到快照中。。。

IMO,我没有文献支持我,但我们各种测试形式之间的关键区别在于范围,

• 集成测试是测试两个或多个相关部分的交互[通常是服务和使用者,甚至是数据库连接,或到其他远程服务的连接]

如果您熟悉单元测试,那么没有完美或“魔弹”测试也就不足为奇了。集成和系统集成测试非常类似于单元测试,因为每个单元测试都是一组测试集,用于验证某种行为。

在实践中,您可能对系统的工作方式有很好的了解,因此编写典型的正路径测试和负路径测试将是自然而然的事。然而,对于任何足够复杂的应用程序,期望每个可能场景的总覆盖率是不合理的。

ps:pet peeve#1:管理者或开发人员称集成和系统集成测试为“单元测试”,仅仅是因为nUnit或MsTest被用来自动化它。。。

为了测试 “真实”应用程序:使http 请求(手动或自动) 用数据库里的一些ID 过程可以自动化,但仍然:

也许你是重复的代码,但你不是重复的努力。单元测试和集成测试有两个不同的目的,通常在SDLC中这两个目的都是需要的。如果可能的话,将用于单元/集成测试的代码分解到一个公共库中。我也会尝试为您的单元/集成测试b/c创建单独的项目

“测试”?

是的,的确如此。

在集成测试中,就像在单元测试中一样,您需要验证测试中发生的事情。在您的示例中,您指定了 OutfileWriter ,则需要某种机制来验证文件和数据是否正常。你真的想自动化这一点,所以你可能想有一个:

Class OutFilevalidator {
    function isCorrect(fName, dataList) {
       // open file read data and
       // validation logic
}

您可以回顾一下markusclermont和johnthomas关于AJAX应用程序自动化测试的一篇演讲“驯服野兽”。 YouTube Video

非常粗略地总结了一个相关的部分:你想使用最小的测试技术,你可以为任何具体的验证。用另一种方法拼写相同的想法,就是尽量减少运行所有测试所需的时间,而不牺牲任何信息。

因此,更大的测试主要是为了确保管道是正确的——标签A实际上是在插槽A中,而不是插槽B中;两个组成部分是否都同意长度是以米为单位,而不是以英尺为单位,以此类推。

在执行代码路径时会有重复,可能您会重用一些设置和验证代码,但我通常不会期望您的集成测试包含在单元级别上发生的相同级别的组合爆炸。

驾驶您的TDD和BDD将涵盖大部分这对你来说。你可以用Cucumber/SpecFlow和WatiR/WatiN。对于每个特性,它都有一个或多个场景,您一次处理一个场景(行为),当它通过时,您将进入下一个场景,直到特性完成。

正如其他人指出的,您当然可以使用集成测试。