开发 DBA 的 TDD 方法？ [关闭]答案

【问题标题】：TDD approaches for Development DBAs? [closed]开发 DBA 的 TDD 方法？ [关闭]
【发布时间】：2013-09-13 14:37:13
【问题描述】：

我公司的软件开发团队使用 TDD 和 BDD 实践进行开发。因此，我们有大量的单元、集成和验收测试来让我们知道我们的代码库是否按预期工作。不用说，如果没有这些测试给我们不断的反馈，我们现在就活不下去了。

我们团队的开发 DBA 编写具有复杂逻辑的表视图。他在没有单元测试的情况下开发这些，并且在他进行后续开发时总是会中断，从而导致软件开发团队感到沮丧。

我的问题是，是否鼓励 DBA 在敏捷环境中工作时使用 TDD 实践？ DBA 是否有测试框架允许他们以这种方式工作？我们使用 IBM 的 DB2 数据库；该数据库是否有任何测试框架允许以 TDD 方式开发数据库视图？

【问题讨论】：

据我所知，没有用于数据库测试的框架，但我想您的 DAO（或您正在使用的任何数据库抽象方法）单元测试应该很好地涵盖数据库更改。跨度>
有用于数据库的单元测试框架，例如tSQLt 并在SQL Server 2012 中引入了一个框架。然而，我最近交谈过的大多数 DBA 似乎没有像软件开发人员那样使用尽可能多的敏捷实践（也许我没有与正确的 DBA 交谈！）。至于测试我们的 DAO/DAL，我们使用集成测试来实现这一点，但正如我所说，这篇文章旨在了解 DBA 是否也使用单元测试在 Scrum Sprint 的开发人员（例如）之前发现错误。
我想知道如何测试视图？你打算在执行时“断言”什么定义或值？
@AngocA 我使用的 DBA 创建视图，其中一些列保存通过处理其他相关表中的数据计算的值。因此，对视图的测试可能是断言某些视图列值符合预期。
@Fresh 据我了解您的评论，您真正想要断言的是查询视图的结果集，而不是视图本身，因为它没有数据。我说的对吗？

【解决方案1】：

过去我使用了两种方法：

在应用程序中有一个非常薄的数据访问层并围绕它编写测试。换句话说（假设您的 dba 使用 sprocs），为每个新的 sproc 编写一个访问它的方法，并创建一个适当地练习它的测试（或者更好的是，首先测试）。这很好，因为它很容易与测试运行程序集成。您可以使用事务回滚测试而不会产生副作用。
另一种选择是使用本机 SQL 测试框架。我评估了tsqlt，它是一个 SQL Server 框架，因此不适合您的情况，但该方法是可靠的，并且可能有适合 DB2 的框架。

【讨论】：

感谢 Sklivvz 的回复。关于第 1 点），我们的 DBA 编写 DB 视图，我们可以编写单元测试来验证表视图中可见的内容是否符合预期。我认为，如果我们这样做，然后鼓励 DBA 密切关注定期运行的测试仪表板，他们就可以看到他们所做的更改是否打破/不打破预期。至于 2)，看起来和SQL Server 2012 中的测试框架一样好。当我重新使用 SQL Server 时，我将不得不使用这些！

【解决方案2】：

有几个框架可以在不同类型的数据库中测试例程。其中一些遵循 xUnit 规范，这允许在数据库级别进行类似 jUnit 的测试。

对于 DB2，有一个名为 db2unit 的框架：https://github.com/angoca/db2unit

使用这个框架，您可以像在 jUnit 中那样比较对象（数字、日期、布尔值、字符串等）。

您可以通过捕获错误代码将数据库级测试的结果包含到全局测试中，这可以包含在持续集成系统中。 db2unit 使用 Travis-CI 进行自我测试。

【讨论】：