【问题标题】:Semi-automated testing of external libraries and error-prone interactions外部库的半自动化测试和容易出错的交互
【发布时间】:2010-03-02 19:43:40
【问题描述】:

最近我一直在尝试在我的代码中使用单元测试,原则上我喜欢这个想法。然而,我最渴望测试的代码部分是那些单靠单元测试不能很好地处理的容易出错的区域;例如:

  • 网络代码
  • 文件系统交互
  • 数据库交互
  • 与硬件的通信(例如通过 RS-232 通信的专用设备)
  • 调用古怪的第三方库

我了解模拟对象通常用于这些情况,但我正在寻找一种方法来确保模拟对象正确模拟我想要测试的情况。

例如,假设我想编写一个模拟数据库服务器重新启动时发生的情况。为此,我想首先验证我正在使用的数据库库是否在重新启动数据库服务器时实际上会引发特定异常。现在,我编写如下代码:

def checkDatabaseDropout():
    connectToDatabase()
    raw_input("Shut down the database and press Enter")
    try:
        testQuery()
        assert False, "Database should have thrown an exception"
    except DatabaseError, ex:
        pass

运行它需要大量的手动干预,但它至少为我提供了一组可验证的假设,我可以在我的代码中使用它,它让我在升级库时检查这些假设,切换到不同的底层数据库等

我的问题是:有没有更好的方法来处理这个问题?是否有支持这种半自动化测试的框架?还是人们通常在测试范围的这一端使用其他技术?

【问题讨论】:

    标签: unit-testing testing automated-tests


    【解决方案1】:

    我尽量不预见这些事情。

    尽管我的 TDD 接近 100%,但归根结底,我仍在构建一个完整的系统,因此我还测试了整个应用程序是否按预期运行。这样的系统测试可以捕捉和重现你所说的那种场景。

    一旦我知道如何重现给定场景,我总能编写一个单元测试来重现它。

    也就是说,我目前倾向于使用两种配置:

    • 全自动单元测试
    • 手动系统测试。

    这些可以交互和相互补充,迭代地使每个更容易更好地使用。

    【讨论】:

    • 可以使用单元测试工具和框架来执行系统测试。您没有模拟,因此设置可能相当复杂。但是,它是明智的,而且效果很好。
    • 同意。严格来说,如果您使用单元测试工具,您会倾向于通过其 API 而不是 UI(如果有 UI)来驱动应用程序。在这些情况下,它不称为系统测试,而是皮下测试。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2022-01-19
    • 1970-01-01
    • 1970-01-01
    • 2010-11-12
    • 2011-06-11
    • 1970-01-01
    相关资源
    最近更新 更多