unit-testing - 单元/集成测试nHibenrate查询

Question

场景：我需要编写一个复杂的nHibernate查询，该查询将返回预计的DTO，但是我想使用TDD方法。该方法如下所示：

public PrintDTO GetUsersForPrinting(int userId)
{
     Session.QueryOver<User>().//some joins, conditions etc.
     //returns projected dto
}

问题：


由于最常见的方法是在内存数据库中使用此类操作。我应该编写集成测试吗？
如果我在内存数据库中使用数据库，我可以编写单元测试吗？
一个测试就足够了吗？
由于我的集成测试可能会检查投影，我该如何命名？ “ GetUserForPrinting_return_correct_DTO”似乎过于抽象和愚蠢。


我问是因为：


关于TDD和集成测试，有很多抽象信息，但是当涉及到具体实现时，很难应用这些信息。
TDD建议集成测试应由单元测试组成：

Answer 1

学习TDD并不是一个很好的问题。我假设您还不知道复杂查询的外观，并且想使用测试驱动的技术将其排除。太棒了:)

但让我们看看我能否回答您的问题。


是
任何包含真实数据库的测试（无论是在内存中还是在磁盘上）都不是单元测试。单元测试将使用模拟数据库。
也许-如果查询足够复杂，则不会。
testGetUsersForPrinting或getUsersForPrintingTest或类似的


我很可能会在SQL解释器中而不是代码中排除查询。目的是根据我在此过程中学到的知识，针对内存数据库进行一系列集成测试。
从您可以想到的最小DTO开始，然后从那里开始建立。

最后将查询转换为nhibernate调用，然后使集成测试通过。

测试驱动，但不是真正的单元测试驱动。

如果您愿意接受最大的TDD纪律，并且比平时工作得更慢，更烦恼，则可以在开发集成测试并编写代码使其通过时自动执行每个集成测试。这意味着您要在3个抽象级别/编辑器/环境（直接SQL查询，集成测试，C＃代码）的3个级别之间频繁切换-我通过设置一些技巧来强制自己每次都遵循正确的步骤来进行处理。

最后一点就是为什么这不是学习TDD的好问题。您可能需要大量的纪律，而您可能还没有强迫自己掌握这些纪律！

祝好运。



好一些具体的例子。我将修改您的代码示例，使其看起来像这样

public PrintDTO GetUsersForPrinting(int userId, ISession session)
{
     var data = session.QueryOver<User>().//some joins, conditions etc.

     return data; // or whatever
}

在单元测试中，您将编写

public testDTO()
{
    //Arrange
    StubSession session = .... setup a stub session, which returns hardcoded values

    // Act
    PrintDTO users = GetUsersForPrinting(111, session);

    // Assert
    Assert.That(users.size(), Is.EqualTo(1));    
    Assert.That(users.get(0).userId, Is.EqualTo(111));

}

在集成测试中，您将使用一个真实的数据库，并且您的会话对象实际上将连接到该数据库，并且将针对该数据库解决查询

布置行为声明是组织单元测试的标准方法。
通常，在单元测试中，您需要尽可能少的断言。您将有多个单元测试。
在编写单元测试时，请先编写“声明”，然后填写其余内容以使其编译/获得所需的结果。首先使测试失败，因为那样您就知道在测试通过时您确实交付了某些东西。

在此示例中，要实现存根ISession，您将从ISession派生一个本地StubSession类（仅对测试套件可见），然后填写绝对最小值以使其能够编译，然后返回最小值数据以使测试通过。



要构建整个DTO（假设您知道DTO想要的内容），请按注释中所述逐步进行。建立DTO的每个部分
一次一块，为每块添加一个单元测试。

跟踪这是TDD的另一项规定。

使用TODO列表进行设置-仅是一个简单的文本文件，或者在测试套件开始时可能需要冗长的注释。列出您要测试的所有内容，例如零个结果，一个结果，两个结果，20个结果。用户ID，以及您需要的其他任何信息。
如果您要对表进行复杂的查询，或者为每个联接，where子句的每个部分添加待办事项，等等。
如果要使用的话，添加用于订购和分页等的项目。

首先选择最简单的东西。一次只能做一个小事情（在一个红绿色重构周期中）。在浏览列表时，您可能希望将项目分解成较小的部分，或者可能会想到需要做的其他事情。将它们添加到TODO列表中，而不是直接对其进行操作。

在这种特殊情况下，我将在每个红绿重构周期之后交换到SQL环境和/或sqlite集成测试中，以弄清楚如何使下一部分工作。我猜这是红色和绿色之间的一种步骤-选择下一步要测试的内容，编写测试（显然失败），在SQL中弄乱直到知道如何通过它，编写nHibernate调用进行测试绿色，然后进行重构。

请注意，列出的某些内容可能没有必要，或者用时太长等。将它们写下来是一件好事，这样您就可以知道正在做什么和正在做什么。专注于您的目标。

我倾向于还会列出“气味”和/或重构的列表，这些列表我可以看到，但我还没有为这个周期做好充分准备。记住要尽量减少重复/重构测试以及SUT（被测系统）。

这是在做而不是看到事情。最终使用什么单元测试以及它们执行的代码的列表并不是对过程的很好描述。肯特·贝克（Kent Beck）最初的TDD书籍比较苗条，可以为您提供一些不错的总体指导，但实际上并不是关于构造查询的。

有什么帮助吗？