使用Apache Spark，我想知道它对于进行测试以及在哪个级别进行测试是否真的很有价值。
阅读Spark: The Definitive Guide时他们建议：
管道中的业务逻辑以及输入数据可能会发生变化。更重要的是，您要确保从原始数据中得出的结论是您实际认为的结论。这意味着您将需要对真实数据进行强大的逻辑测试，以确保您真正从中得到想要的东西。
建议引入某种测试。
但是让我印象深刻的是：
这里需要警惕的是，尝试编写一堆“火花单元测试”来测试Spark的功能。您不想这样做；相反，您想测试您的业务逻辑，并确保您设置的复杂业务管道实际上正在按照您认为应该做的事情进行。
这概述了本书的作者不鼓励进行单元测试（如果我误解了，请纠正我）。
可能值得测试的是通过Spark应用的数据转换的逻辑。
这本书再次出现：
首先，您可能需要维护一个暂存空间，例如交互式笔记本或类似的笔记本，然后在构建关键组件和算法时，将它们移动到更持久的位置（如库或包）。笔记本体验是我们经常推荐（并经常用来编写本书）的一种体验，因为它的实验非常简单
建议在交互式环境（例如笔记本电脑（例如，用于Pyspark的Jupyter笔记本电脑））中测试数据转换逻辑。基本上，您可以直接看到转换产生的结果。
因此，我要问的是比我有更多经验的人，您是否同意书中提到的观点？ （或者我会误解）可以将它们用作该领域的一种最佳实践吗？（例如避免单元测试，取而代之的是诸如逻辑/集成测试的高级测试）
答案 0 :(得分：1)
该声明并不是要避免单元测试。就是说，要避免对业务没有价值的测试数据，如果不这样做，您最终将测试spark api，而不是业务组件。例如，您已经在spark UDF中编写了一个函数来进行汇总，因此在编写单元测试时，请确保将真实的数据提供给函数，以模拟生产环境。
借助zeepline这样的笔记本电脑体验，您可以将所有阶段都集中在一个地方，例如数据提取，可视化。它确实与数据管道互动