单元测试应用程序逻辑和不信任的语言构造之间的界线在哪里？

function savePeople(dataStore, people) {
    people.forEach(person => dataStore.savePerson(person));
}

myDataStore = new Store('some connection string', 'password');
myPeople = ['Joe', 'Maggie', 'John'];
savePeople(myDataStore, myPeople);

function bakeCookies(dough, pan, oven) {
    panWithRawCookies = pan.add(dough);
    oven.addPan(panWithRawCookies);
    oven.bakeCookies();
    oven.removePan();
}

#1 楼

savePeople()应该进行单元测试吗？是。您不是要测试dataStore.savePerson是否有效，或者数据库连接是否有效，甚至foreach是否正常。您正在测试savePeople是否履行了其通过合同作出的承诺。

想象这种情况：某人对代码库做了很大的重构，并意外地删除了实现的forEach部分，因此它总是保存第一项。您不想让单元测试抓住这一点吗？

#2 楼

通常，当人们进行“事后测试”开发时会出现这种问题。从TDD的角度解决此问题，在实施之前先进行测试，然后再练习一次问自己这个问题。

至少在我通常是外而内的TDD应用程序中，在实现savePeople之后，我将不会实现类似savePerson的功能。 savePeople和savePerson功能将作为一个功能开始，并由相同的单元测试进行测试驱动。在重构步骤中，经过几次测试后，两者之间就会出现分离。这种工作方式还会带来一个问题，即函数savePeople应该在哪里-它是自由函数还是dataStore的一部分。

最后，测试不仅会检查您是否可以正确地将Person保存在Store中，但也可以保存很多人。这也将使我产生疑问，例如是否需要进行其他检查，例如“我是否需要确保savePeople函数是原子函数，要么全部保存要么不保存？” “不会被保存？这些错误看起来如何？”，依此类推。所有这一切都不仅仅是检查forEach或其他形式的迭代的使用。然后，我将更新savePerson的现有测试以通过新功能savePerson运行，以确保它仍然可以通过简单地委派一个人来挽救一个人，然后通过新测试来测试一个以上人的行为，并考虑是否必须使该行为具有原子性。

#3 楼

应该对savePeople（）进行单元测试


是的，应该。但是，请尝试以与实现无关的方式编写测试条件。例如，将您的使用示例转换为单元测试：

function testSavePeople() {
    myDataStore = new Store('some connection string', 'password');
    myPeople = ['Joe', 'Maggie', 'John'];
    savePeople(myDataStore, myPeople);
    assert(myDataStore.containsPerson('Joe'));
    assert(myDataStore.containsPerson('Maggie'));
    assert(myDataStore.containsPerson('John'));
}

此测试可以执行多项操作：函数savePeople()的合约

它并不关心savePeople()的实现

它记录了savePeople()的示例用法


请注意，您仍然可以模拟/存根/伪造数据存储。在这种情况下，我将不检查显式函数调用，而是检查操作结果。这样，我的测试就为将来的更改/重构做好了准备。

例如，您的数据存储实现将来可能会提供saveBulkPerson()方法-现在对savePeople()的实现进行更改以使用saveBulkPerson()不会失败只要saveBulkPerson()可以正常工作，就可以进行单元测试。并且如果saveBulkPerson()不能按预期方式工作，则您的单元测试将捕获该问题。 />
如前所述，请尝试测试预期结果和功能接口，而不是实现（除非您正在执行集成测试-然后捕获特定的函数调用可能有用）。如果有多种方法来实现功能，则所有方法均应与单元测试一起使用。

关于问题的更新：

测试状态变化！例如。一些面团将被使用。根据您的实现，断言dough的使用量适合pan，或者断言dough已用完。在函数调用后，断言pan包含cookie。断言oven为空/处于与以前相同的状态。

对于其他测试，请验证边缘情况：如果在调用之前oven不为空，会发生什么？如果dough不够，会发生什么？如果pan已经满了？

您应该能够从面团，平底锅和烤箱的物体本身推断出这些测试所需的所有数据。无需捕获函数调用。

实际上，大多数TDD用户在编写函数之前就编写了测试，因此他们并不依赖于实际的实现。


对于最新添加的内容：


当用户创建新帐户时，需要进行以下操作：1）需要创建新的用户记录在数据库中创建2）需要发送欢迎电子邮件3）为了欺诈目的，需要记录用户的IP地址。

因此，我们想创建一种将所有“新用户”联系在一起的方法“步骤：

function createNewUser(validatedUserData, emailService, dataStore) {
    userId = dataStore.insertUserRecord(validateduserData);
    emailService.sendWelcomeEmail(validatedUserData);
    dataStore.recordIpAddress(userId, validatedUserData.ip);
}

对于这样的函数，我会模拟/存根/伪造（无论看起来更通用）dataStore和emailService参数。该函数不对任何参数单独进行任何状态转换，而是将它们委托给其中一些方法。我会尝试验证对函数的调用是否完成了4件事：


它将用户插入到数据存储中
发送（或至少调用了相应的方法）一封欢迎电子邮件
，它将用户IP记录到数据存储中。
它委派了它遇到的任何异常/错误（如果有的话）

前三项检查可以通过模拟进行， dataStore和emailService的存根或伪造品（您确实不想在测试时发送电子邮件）。由于我不得不查找一些注释，因此有以下区别：


伪品是指与原始物品具有相同行为且在一定程度上无法区分的物体。它的代码通常可以在测试之间重用。例如，这可以是用于数据库包装程序的简单内存数据库。
存根只是实现了满足此测试所需操作所需的尽可能多的内容。在大多数情况下，存根特定于一个测试或一组测试，只需要原始方法的一小部分即可。在此示例中，它可能是dataStore，仅实现了insertUserRecord()和recordIpAddress()的合适版本。
模拟是一个对象，可让您验证其用法（通常是通过评估对其方法的调用来实现）。我会尝试在单元测试中谨慎使用它们，因为通过使用它们，您实际上是在测试功能实现，而不是对其接口的遵循性，但是它们仍然有其用途。存在许多模拟框架可帮助您仅创建所需的模拟。


请注意，如果这些方法中的任何一个引发错误，我们都希望该错误冒泡至调用代码，因此它可以处理它认为合适的错误。如果被API代码调用，则可能会将错误转换为适当的HTTP响应代码。如果通过Web界面调用它，则可能会将错误转换为适当的消息以显示给用户，依此类推。关键是此函数不知道如何处理可能引发的错误。


预期的异常/错误是有效的测试用例：如果发生此类事件，您可以进行确认。如果发生这种情况，该功能将按照您期望的方式运行。这可以通过在需要时让相应的模拟/假/桩对象抛出来实现。


我的困惑的本质是，对这种功能进行单元测试似乎需要重复精确的操作。测试本身中的实现（通过指定以某种顺序对模拟进行调用的方法），这似乎是错误的。


有时这是必须要做的（尽管您在集成测试中最在乎这一点）。更常见的是，还有其他方法可以验证预期的副作用/状态变化。

验证确切的函数调用会导致相当脆弱的单元测试：仅对原始函数进行很小的更改就会导致它们失败。这可能是不希望的，但是每当您更改功能时（例如重构，优化，错误修复...），都需要更改相应的单元测试。

遗憾的是，在这种情况下，单元测试会失去一些可信度：由于更改了单元测试，因此更改后的功能与以前相同，因此无法确认功能。

例如，考虑有人添加了呼叫到cookie烘焙示例中的oven.preheat()（优化！）：


如果模拟了烤箱对象，尽管该方法的行为是可观察的，但它不会期望调用并导致测试失败不会改变（希望您仍然有很多cookie）。
存根可能会失败，也可能不会失败，这取决于您是仅添加要测试的方法还是使用一些虚拟方法添加整个接口。 >伪造不应该失败，因为它应该实现方法（根据接口）

在我的单元测试中，我尝试尽可能通用： nges，但可见的行为（从调用者的角度来看）仍然相同，我的测试应该通过。理想情况下，我唯一需要更改现有单元测试的情况应该是错误修复（测试的缺陷，而不是测试中的函数）。

#4 楼

该测试提供的主要价值是使您的实现可重构。

我在职业生涯中曾做过许多性能优化，并且经常发现与您演示的确切模式有关的问题：保存N个实体进入数据库，执行N次插入。通常，使用单个语句进行批量插入会更有效。

另一方面，我们也不想过早优化。如果通常一次只能节省1-3个人，那么编写优化的批处理可能就太过分了。

通过适当的单元测试，可以按照上面的实现方式进行编写，如果您如果发现您需要对其进行优化，则可以通过自动测试的安全网自由地进行操作，以捕获任何错误。自然，这取决于测试的质量，因此请进行自由测试并进行良好的测试。

对这种行为进行单元测试的第二个好处是可以用作其目的的文档。这个琐碎的例子可能很明显，但是鉴于下面的要点，它可能非常重要。很难通过集成或验收测试来测试。例如，如果要求原子存储所有用户，那么您可以为此编写一个测试用例，这使您可以了解其行为是否符合预期，并且还可以作为该需求的文档给新的开发人员。

我将添加我从TDD讲师那里得到的想法。不要测试该方法。测试行为。换句话说，您并没有测试savePeople是否有效，而是在一次呼叫中可以保存多个用户。

当我停止将单元测试视为验证程序正常工作时，我发现我进行质量单元测试和TDD的能力得到了提高，但是，他们却验证了代码单元是否符合我的期望。那些是不同的。他们没有验证它是否有效，但他们验证了它是否符合我的想法。当我开始以这种方式思考时，我的观点发生了变化。

#5 楼

应该对bakeCookies()进行测试吗？是的。


假设您认为应该对这样的函数进行单元测试？我很难想像任何类型的单元测试都不能简单地模拟面团，锅和烤箱，然后断言在它们上调用了方法。仔细查看该函数应该执行的操作-应该将oven对象设置为特定状态。查看代码，看来pan和dough对象的状态并没有多大关系。因此，您应该传递oven对象（或对其进行模拟），并在函数调用结束时断言该对象处于特定状态。

换句话说，您应断言bakeCookies()烘烤了cookie。

对于非常短的功能，单元测试似乎只不过是重言式。但是请不要忘记，您的程序将比您受雇编写程序的时间更长。该功能将来可能会更改，也可能不会更改。

单元测试具有两个功能：


它测试一切正常。这是单元测试所用的最不有用的功能，而且看来您似乎只在询问问题时才考虑使用此功能。这是单元测试中最有用的功能，它可以防止将错误引入大型程序。在向程序添加功能时，它在常规编码中很有用，但在重构和优化时（在不改变程序任何可观察行为的情况下，实现程序的核心算法发生了显着变化）则更有用。不要测试函数内部的代码。而是测试该功能是否按照其说明的方式工作。当您以这种方式看待单元测试（测试功能，而不是代码）时，您将意识到您永远不会测试语言构造甚至应用程序逻辑。您正在测试API。

#6 楼

应该对savePeople（）进行单元测试，还是将这些测试等同于测试内置的forEach语言构造？


是。但是您可以用一种可以重新测试构造的方法来实现。它应该如何工作？

函数应该提供这种微妙的行为，您应该在单元测试中强制执行。

#7 楼

关键是您对特定功能的琐碎看法。大部分编程都是微不足道的：分配一个值，做一些数学运算，然后做一个决定：如果是，那就继续循环，直到...孤立地说，所有这些都是微不足道的。您刚刚读完任何教编程语言的书的前5章。

编写测试是如此容易的事实应该表明您的设计还不错。您愿意不容易测试的设计吗？

“这永远不会改变。”是大多数失败的项目开始的方式。单元测试仅确定在某些情况下单元是否按预期工作。让它通过，然后您就可以忽略它的实现细节，而只需使用它即可。将大脑空间用于下一个任务。

知道事情如预期的那样非常重要，在大型项目尤其是大型团队中并非易事。如果程序员有一个共同点，那就是我们所有人都必须处理别人的糟糕代码的事实。我们至少可以做的是进行测试。如有疑问，请编写测试并继续。

#8 楼

是否应该对savePeople（）进行单元测试，或者这样的测试是否等同于测试内置的forEach语言构造？还有一些额外的参数（我想）：

首先，单元测试用于测试合同的履行，而不是API的实现；测试应设置先决条件然后调用，然后检查效果，副作用，任何不变性和后期条件。当您决定测试什么时，API的实现无关紧要。

其次，当函数更改时，您的测试将在那里检查不变量。现在它不会改变的事实并不意味着您不应该进行测试。

第三，在TDD方法（强制执行该方法）中实施微不足道的测试很有价值。

在编写C ++时，对于我的类，我倾向于编写一个琐碎的测试，以实例化一个对象并检查不变量（可赋值，常规等）。我发现令人惊讶的是，此测试在开发过程中被破坏了几次（例如-通过在类中添加一个不可移动的成员，这是错误的）。

#9 楼

我认为您的问题可以归结为：

如果不将其作为集成测试，如何对void函数进行单元测试？例如，可以立即看出测试应该是什么。平移对象？'

我认为您是对的，因为对所有内容进行了模拟的单元测试以及仅检查函数xy和z被称为缺少值。

但是！我认为在这种情况下，您应该重构void函数以返回可测试的结果或使用真实对象并进行集成测试

---更新createNewUser示例


需要在数据库中创建新的用户记录
需要发送欢迎电子邮件
出于欺诈目的，需要记录用户的IP地址。

确定，因此这次函数的结果不容易返回。我们要更改参数的状态。

这是我引起争议的地方。
我为有状态参数创建具体的模拟实现

，亲爱的读者，请尝试控制您的愤怒！

如此...

var validatedUserData = new UserData(); //we can use the real object for this
var emailService = new MockEmailService(); //a simple mock which saves sentEmails to a List<string>
var dataStore = new MockDataStore(); //a simple mock which saves ips to a List<string>

//run the test
target.createNewUser(validatedUserData, emailService, dataStore);

//check the results
Assert.AreEqual(1, emailService.EmailsSent.Count());
Assert.AreEqual(1, dataStore.IpsRecorded.Count());
Assert.AreEqual(1, dataStore.UsersSaved.Count());

这将被测方法的实现细节与所需行为分开。一个替代实现：

function createNewUser(validatedUserData, emailService, dataStore) {
  userId = dataStore.bulkInsedrtUserRecords(new [] {validateduserData});
  emailService.addEmailToQueue(validatedUserData);
  emailService.ProcessQueue();
  dataStore.recordIpAddress(userId, validatedUserData.ip);
}

仍将通过单元测试。另外，您还具有能够在测试中重用模拟对象并将其注入到应用程序中以进行UI或集成测试的优势。

#10 楼

您还应该测试bakeCookies-例如，bakeCookies(egg, pan, oven)会产生什么？煎蛋还是例外？ pan和oven都不会对它们的实际成分感兴趣，因为它们都不应该这样做，但是bakeCookies通常应该产生cookie。更一般而言，它取决于如何获得dough以及是否有可能成为egg或例如。 water代替。