JavaScript/TypeScript 中的 TDD 最佳实践

Question

问题

• 访问模块中的所有 JavaScript/TypeScript 函数以进行单元测试的正确/可接受的方式是什么？
• 我不应该只导出所有函数是否有（充分的）理由？

上下文

请原谅我的无知；我的大部分职业生涯都在使用测试驱动开发 (TDD) 方法编写 Python 代码。现在，我发现自己正在学习 ReactJS/TypeScript 并弄清楚如何实现单元测试，但我很快发现只有导出函数才能访问它们。大多数人都知道，Python 是非常宽松的。确实没有隐私的概念，因此只需导入模块并尊重您可以访问的内容。但 JavaScript 只导入已显式导出的模块的功能，因此提供了适度的障碍。

有人告诉我，导出所有函数进行测试不是一个好主意，但我不知道有另一种方法可以实际测试它们。

示例

我被告知的是“正确/更好”：

Sample1.js：

const func1 = () => {
    //code that does stuff
    return "stuff";
};

const func2 = () => {
   //code that does other stuff
   return "otherStuff";
};

export { func1 };

Sample1.test.js：

// executed via Jest framework

import * as sample from "./Sample1.js"

describe("Unit Tests for Sample1", () => {
    test("Unit Test - func1", () => {
        // code that tests stuff
    };

    test("Unit Test - func2", () => {
        // can't test func2 because it's not exported
    };
};

为了能够测试所有功能，我正在做什么：

Sample2.js：

const func1 = () => {
    //code that does stuff
    return "stuff";
};

const func2 = () => {
   //code that does other stuff
   return "otherStuff";
};

export { func1, func2 };

Sample2.test.js：

// executed via Jest framework

import * as sample from "./Sample2.js"

describe("Unit Tests for Sample2", () => {
    test("Unit Test - func1", () => {
        // code that tests stuff
    };

    test("Unit Test - func2", () => {
        // code that tests other stuff because it's exported
    };
};

记录在案

我专门在 Internet 和 Stack Overflow 上查看了标准和最佳实践，但我没有找到太多可以回答这个特定问题的内容。我找到的最接近的是this SO question，但这并不是我真正想要的。

Answer 1

如果您真正通过在被测系统 (SUT) 之前编写测试 来进行测试驱动开发 (TDD)，那么您可以将测试视为 SUT 的可执行规范。 （如果这对您来说已经很明显了，我很抱歉，但是 Stack Overflow 上的许多人将 TDD 与单元测试互换使用，并说他们执行 TDD，即使他们在 SUT 之后编写测试。）

因此，测试描述了 SUT 的 API。在具有access modifiers 和/或显式导出功能的语言中，您需要使 SUT 可用于测试。在 JavaScript 中，这确实意味着您必须导出要测试的 API。在具有访问修饰符的其他语言中，这也意味着您必须为 SUT API public 提供可用性（例如 Java 和 C#）。

如果您正在开发一个库，这也将与客户端代码可用的 API 相吻合。事实上，测试是 SUT 的第一个（或最早的）客户端。

测试到位后，它们将作为 SUT 的回归测试套件。因此，如果测试失败，则表明导出的 API 的某些部分已损坏。这也意味着该部分将被使用它的客户端代码破坏。

那么你应该导出所有方法吗？

不一定。您可能希望隐藏一些方法作为实现细节。这可能有各种充分的理由。也许您不确定帮助方法的 API 是否健壮，并且您希望保留在不破坏客户端代码的情况下更改它的能力。可能是辅助方法封装不好。

只要在 TDD 过程中创建了此类辅助方法，它们就会still be transitively covered by tests，即使它们本身没有被导出。