今天我对单元测试进行了很多思考，对于在测试驱动开发 (TDD) 过程中究竟如何创建单元测试感到有点困惑。 （需要明确的是，对我来说，单元测试是针对代码库的最小范围进行测试（即“isPrime”或“hasThisValue”等函数。所以像“GetUserData”这样的东西不是单元测试，而是一个功能（或实际软件的行为）））。
对我来说，TDD 从来不是从一个实际的单元开始，而是从一个想要的功能开始，所以例如“测试_获取用户数据”。现在我编写测试，它失败了，我修复它，它有效，然后重构。在此重构步骤中，我将创建多个单元（例如“hasAdminStatus”作为函数）。 所以我的问题是：什么时候为这些重构单元编写测试？我现在不能在编写实际代码之后继续编写它们，因为这违背了 TDD 的理念。如果从来没有为这些编写测试，那么单元测试（因为这些显然是单元）到底是如何用 TDD 编写的？ 希望你们能理解我的问题，非常感谢您的阅读。
（BDD），尽管这通常与 Gherkin 语言混淆（Given When然后）。 “由外向内 TDD”的对立面并不像人们想象的那样被称为“由内向外 TDD”，而是“自下而上 TDD”。在这里，您从一些非常细粒度的东西开始，并为此编写一个测试。这通常是对象上的函数或方法。 如果您的任务是开发可重用的库，这非常有用。想象一下，您的任务是编写一个可重用的数学函数库、安全算法或绘图程序。在这种情况下，从单元测试开始似乎更合适，因为所需的交付工件是可重用的代码，而不是完整的应用程序。
一旦您发布了库的第一个版本，这些单元测试现在就是回归测试，并防止重大更改。 尽管如此，还没有普遍接受的测试术语。我所说的单元测试，你可能不会称之为单元测试，反之亦然。