使用Azure函数和TDD进行快速原型制作

我有个主意

我的一位同事达里奥（Dario）生日快乐。

办公室里的每个人都很高兴收到Dario的音频问候。 他们说：“ 直到Dario向您致以问候，这才是生日。 ”

那么，为什么不让Dario在世界各地生日那天迎接世界上的所有人呢？您想尝试一下吗？

https://telegram.me/HappyDarioBot

目前只有意大利语（抱歉）。

Github仓库在这里：

https://github.com/lucapiccinelli/HappyDarioBot

好。 怎么样？

我需要一种简单的方法来让人们问好。 网站？ 在平台时代谁仍然使用网站？ 然后平台。 哪一个？ Facebook的？ 推特？ 还是电报？ 通常，Dario使用WhatsApp分发他的音频笔记。 我想让他留在他的舒适区，但是您可能知道WhatsApp在机器人开发上有很多限制。 因此， Telegram是选择 ！

好。 哪里？

在哪里托管机器人？ 答案取决于业务需求和技术选择。 在项目的这个阶段，我需要保持快速！ 我不想花时间在可能没人会使用的东西上。 我需要知道是否有人会尽快使用它。 因此， 快速是重中之重 。 目前，我正在用Kotlin进行开发，但是随着我用C＃进行多年开发，它仍然是我最有效的语言。

我还需要存储音频文件和一些简单的非结构化信息。

用C＃托管可以访问简单存储的东西的更快方法是什么？ 答案是无服务器托管。 对于C＃， Azure函数 。

质量

我快速地说，这并不意味着我接受低质量的代码。 在有人要使用它的幸运场景中，我想让它增长而无需重写所有内容。

如何快速并保持可接受的代码质量水平？ 测试驱动的开发就是答案 。 我去深约我的经验，它在这里 。 总而言之，要习惯它需要一些时间和实践，但是一旦您熟悉了它， 它便是在现实世界中开发和交付某些东西的最快方法 。

实际上，提高速度不仅与TDD有关。 这是技术的黄金三合会：

1. TDD →确保您的业务价值安全
2. 渐进式方法 →只做您已经知道的有价值的事情
3. 设计简单 →保持简单模块化

这些是相关的。 TDD支持增量方法。 增量方法可改善简单设计。

如何使用Azure函数进行TDD

TDD一点也不琐碎 。 最难回答的问题之一是“要测试什么？”

HappyDarioBot Azure功能正在通过电报webhook接收电报更新。 然后，它处理更新并发回电报消息。 该答复消息取决于某些业务逻辑。

好像我既不拥有输入也不拥有输出。

那要测试什么？ 我是否应该通过HTTP向机器人发布请求，然后使用一些Telegram API来确保已实际收到消息？ 需要多长时间？ 这个测试代码有多复杂？

我们不是质量检查人员。 我们是开发商。 我们的重点不是“为了测试而测试”，而是“为了开发而测试” 。

让我们开始切掉一些东西。 当我使用无服务器架构时，我可以确定该基础架构可以正常工作 。 因此，我不需要通过HTTP执行真实的发布即可确保我的功能将按预期被触发。 我可以直接按其类直接调用Azure函数。 这省去了我发现应该如何在本地启动Azure功能以通过HTTP进行响应的工作。

我没有输入格式，因为它是来自Webhook的Telegram。 我如何获得一些输入进行测试？

看下面的代码：

[ FunctionName( "HappyDarioBot" ) ]
public static async Task<HttpResponseMessage> Run ( [HttpTrigger(WebHookType = "genericJson" )]HttpRequestMessage req, ILogger log)
{
    log.LogInformation( "DarioBot was triggered!" );
    string jsonContent = await req.Content.ReadAsStringAsync();
    log.LogInformation(jsonContent);
    
    return req.CreateResponse(HttpStatusCode.OK);
}

这是该机器人的第一个版本。

反序列化HTTP请求的内容后， 我将其记录下来 。 我将其部署在Azure上，注册了Webhook，并在Telegram上向该机器人发送了一条消息。 然后我去了Azure门户中的日志监视。 在那里，我有输入样本 。 我将其复制并粘贴到测试中，然后完成。 对所需的每种输入类型（以及某些意外的形式）重复该过程。

那输出呢？

在这里也要简化。 通常，在测试第三方API时，您无法检查调用在其系统上触发的状态更改。 您依赖的事实是， 如果API回答OK，那么就可以了 。

和这里一样。 在此测试级别，我对工作的定义是“该功能可以正常运行”。 就这样。

还有业务逻辑？ 我怎么知道它实际上在做什么？ 带有单元测试。

发现业务逻辑将被移交给协作者是很简单的。 业务逻辑不得依赖任何基础架构 。 这样，通过单元测试就可以轻松对其进行测试。

结论

我没有追踪开发HappyDarioBot花了多长时间。 但是，我估计总共需要25到30个小时 。 一些注意事项：

• 我以前从未在Azure上开发过东西。
• 我以前从未开发过Telegram机器人。
• 我每天大部分时间要做一个小时的工作。 这与关注8小时不同。

总结一下，我想说，作为对无服务器架构的第一次测试，我对结果感到满意。 您必须学习如何使用平台的工具，但是作为开发人员， 您可以100％专注于开发 。

如果您想使用产品的可用原型/ alpha版本尽快达到目标，我建议您考虑使用无服务器。 如果您是C＃开发人员，则可以在Azure上感到宾至如归。

From: https://hackernoon.com/fast-prototyping-with-azure-functions-and-tdd-m7xb32c2