【发布时间】：2019-11-15 23:35:14
【问题描述】：
是否有人使用 BDD 测试大数据 ETL 应用程序？ 我可以看到如何使用 BDD 来测试与客户端交互的应用程序，但在大数据 ETL 应用程序的情况下，没有客户端交互，因此很难看出我可能会使用什么“何时”。 例如： 给出 100 个 A 类事件发生 5分钟后发生50个B型事件 那么数据库行应该是： |类型|计数|桶| |A|100|1| |B|50|2|
但这似乎是错误的。 有哪位有见识的吗？
【问题讨论】：
【发布时间】：2019-11-15 23:35:14
【问题描述】：
您能否举例说明您希望在 ETL 输出中看到什么？
您可以对此给出几个回答。一种可能是您所期望的不同类型的数据库行，其中一些可能会重复，而其他的则不会。这让我觉得很奇怪，但如果您习惯使用星型模式，那么您可能会注意到其他差异。
通常我会引导人们远离谈论数据库，但如果您使用星型模式，我认为提及事实和维度是可以的（我没有经常使用 ETL，但我会请记住通过这些具体示例以及我希望看到的内容进行讨论）。
另一种方法是使用客户端。
我看到你说没有客户；然而，总是有一个客户，即使它可能在未来存在。 ETL 涉及安全性、性能和访问等方面的影响。值得拥有一个客户端，即使它是一个基于字符串或基于 SQL 的玩具，来探索可能会绊倒你的事情。
你为什么要这样做？企业或用户或客户在实施后将能够做的事情有什么新的东西，而他们已经不能做？你能举个例子吗？
“我们将能够了解 X 在 Y 标准下的表现如何。”
太好了。你能给我一个X、Y和一些标准的例子吗？您将如何衡量绩效？您要查找哪些数据？每个人都应该能够看到这些数据吗？你能想到任何人不应该能够访问它的场景吗？
这些示例成为场景的 ETL 等价物；对话保持相同的模式。你最终只是在不同的层次上实现了自动化，因为你的 API 是面向机器的而不是面向人的，而且你的一些对话将是关于监控而不是测试的。您的对话仍应与人们进行。
您的“何时”将是您在运行它的数据、权限和安全上下文中运行的查询或报告。
【讨论】：
-
这是一个关于“何时”的有趣见解，我的问题是：我们不付出额外的努力来适应 BDD 吗？这种情况下的行为非常繁琐，以至于我的句子无法阅读，我给出了一个不适合任何 ETL 的简单示例，因为通常 ETL 是关于数据的确切结构，“Given”可能是描述结构
-
我认为人们很多时候都会过度思考 BDD。坚持回答“你能给我举个例子吗？”任何出来的东西通常都会有正确的语言。不过，并非所有东西都适合自然语言——而且星型图也不是特别直观！ - 因此，如果您的示例更适合表格，请使用表格。如果它只会被技术人员而非业务人员阅读，那么也可以使用代码来描述这些内容。
-
在我看来，最好的方法是拆分业务行为，使用系统测试中的美好一天场景（用于数据结构）（为所有边缘情况操作数据结构）。如果完全使用 BDD，则可以审查系统测试。我唯一担心的是系统测试和业务需求之间的联系会丢失。
-
企业总是需要一些新功能。问：“我们/我们的客户/我们的分析师/等将能够做哪些他们现在无法做到的事情？”如果 ETL 中包含的信息是新事物，则将玩具客户端敲入它并在其上编写场景。如果客户是新事物，而您只是支持该客户，则让客户开发人员为该客户制定方案并与他们合作以支持它。客户端可能是一个 SQL 报告而不是一个特定的 UI，但它会是某人使用的东西。这将帮助您保持链接。
BDD 始终适用于大数据空间内的应用程序逻辑。记住测试三角原理。进行单元测试。练习 BDD，并在您的 sprint 中使用 BDD 构建集成和验收测试。不建议在外部维护您的测试数据，因此验证所有移动部件的 E2E 流程需要轻量级。如果允许，练习 TDD 模型。
【讨论】：