我正在学习TDD,我目前有一种方法可行,但我认为我可以使用TDD重建它。
该方法基本上需要6个参数,查询数据库,执行一些逻辑并返回List<T>
我的初步测试包括检查空/零定义的字符串和int方法参数值,但现在我不知道该怎么做。如果我没有使用TDD,我只需创建代码来查找数据库连接字符串并打开数据库连接,查询数据库,读取值等。
显然我们不能在单元测试中这样做,所以我在听取了一些如何进行的建议。
答案 0 :(得分:9)
请记住,TDD与良好的设计有关,而不是测试。这种方法有太多的进展;它违反了“关注分离”原则。
您已经确定了需要测试的几个方面:
该方法基本上需要6个参数,查询数据库,执行一些逻辑并返回
List<T>
那里有几个不连续的步骤,代码中可能还有一些隐藏的步骤。打破这些是TDD游戏的名称。
对于初学者来说,分解执行逻辑的部分可能是个好主意。
您的方法是否动态构建查询?打破这一部分并测试它以确保查询正确写入。
您可以将查询的执行放入独立的存储库或类似的存储库中,并针对该存储库编写集成测试。这样,您只需要对数据库进行简单的测试,而不是使用当前的复杂方法。
如果您尝试按原样进行测试,您可能最终会进行怪物测试,需要进行大量设置并复制您的所有业务逻辑,并且当它打破时,它将不清楚出了什么问题。
答案 1 :(得分:6)
一般来说,使用TDD测试数据库代码并没有“错误”。但是,您可能会尝试抽象出数据库代码,然后嘲笑它。
答案 2 :(得分:4)
该方法基本上需要6个参数,查询数据库,确实如此 一些逻辑并返回一个List
对于单元可测试代码来说,似乎 太多了
单元可测试代码应该做非常具体的事情,并在小模块中进行。所以,在你的情况下,你需要重构并破坏你的方法(至少):
此外,请记住,单元测试应涵盖每个可测试模块的至少三个方案:
希望这有用。
答案 3 :(得分:2)
另一种选择是在测试之前启动事务并在之后进行回滚。这种方式测试是独立的,因此根据一些定义,仍然可以考虑单元测试。
与其他答案中提到的内容相反,您应该重构代码,以便在测试通过后获得更好的设计。然后,您可以通过重新运行测试来验证您的重构没有破坏任何内容。
答案 4 :(得分:1)
您可能想尝试查看DbUnit在数据访问层上运行单元测试。它使您的数据库在测试运行之间处于已知状态,从而防止测试数据库损坏。
答案 5 :(得分:1)
你可以:
这测试你的单位但被一些人认为是“整合测试”。 - 由于“单位”一词含糊不清,“单元测试”一词存在一些分歧。
您还可以使用内存数据库或进程内数据库来简化测试环境。