TDD ...how？

Question

我即将开始我的第一个测试驱动开发(测试驱动开发)程序，我(自然地)有一个测试驱动开发mental block..so，我想知道是否有人可以帮助我指导我应该从哪里开始。

我正在创建一个函数，它将从套接字读取二进制数据，并将其数据解析为一个类对象。

据我所知，有3个部分：

1)解析数据的逻辑2)套接字类3)类对象

我应该采取哪些步骤才能以增量方式进行TDD？我绝对计划在实现函数之前先编写测试。

Answer 1

测试驱动开发中的问题是“可测试性设计”。

首先，您必须有一个用来编写测试的接口。

要做到这一点，你必须对你的可测试单元有一个大致的概念。

1. 某个类，它是由函数构建的。
2. 某个函数，它从套接字读取并发出一个类。

其次，给定这个粗略的接口，将其形式化为实际的非工作类和函数定义。

第三，你开始编写你的测试--知道他们会编译但是失败了。

在此过程中，您可能会开始对您的函数感到困惑。如何为您的函数设置套接字？这是一个令人头痛的问题。

然而，你上面勾勒出的界面并不是法律，它只是一个好主意。如果您的函数接受一个字节数组并创建一个类对象，结果会怎样？这是非常非常容易测试的。

因此，重温这些步骤，更改接口，编写非工作类和函数，现在编写测试。

现在，您可以填充类和函数，直到所有测试通过。

当您完成这一点测试后，您所要做的就是挂接到一个实际的套接字中。您信任套接字库吗？(提示:您应该)在这里测试不多。如果您不信任套接字库，那么现在您必须提供一个可以以受控方式运行的数据源。这是一个巨大的痛苦。

Answer 2

你的分成听起来很合理。我认为这两个依赖项是输入和输出。你能让他们减少对具体生产代码的依赖吗？例如，您能让它从一般的数据流而不是套接字读取吗？这将使传递测试数据变得更容易。

返回值的创建可能更难模拟，而且可能无论如何都不是问题-用于结果对象的实际填充的逻辑是否相当简单(在解析之后)？例如，它基本上只是设置琐碎的属性吗？如果是这样，我就不会费心在那里引入工厂等--只需输入一些测试数据并检查结果即可。

Answer 3

‘最好的测试框架是应用程序本身’

我认为开发人员中的一个常见误解是，他们错误地将测试框架和TDD原则联系在一起。我建议重新阅读有关TDD的官方文档；请记住，测试框架和TDD之间没有真正的关系。毕竟，TDD是一个范例，而不是一个框架。

通过阅读wiki on TDD (https://en.wikipedia.org/wiki/Test-driven_development)，我开始意识到，在某种程度上，事情是可以解释的。

TDD有不同的个人风格，这主要是因为TDD原则是可以解释的。

我在这里并不是说任何人都是错的，但我想与你们分享我的技术，并解释它们是如何为我服务的。请记住，我已经编程36年了；这使我的编程习惯得到了很好的发展。

1. 代码重用被高估了。过多地重用代码，你最终会得到糟糕的抽象，而且在不影响其他东西的情况下，修复或更改一些东西将变得非常困难。最明显的优点是减少了manage.
2. Repeating的代码，太多的代码会导致代码管理问题和代码库过大。然而，它确实有很好的关注点分离的优势(能够在不影响应用程序其他部分的情况下调整、更改和修复事情)。
3. 不要重复/重构太多，不要重用太多。代码需要是可维护的。理解和尊重代码重用和关注点的抽象/分离之间的平衡是很重要的。

在决定是否重用代码时，我的决定基于：....在整个应用程序代码库中，此代码的性质是否会在上下文中发生变化？如果答案是否定的，那么我会重用它。如果答案是肯定的，或者我不确定，我重复/重构它。然而，我会不时地修改我的代码库，看看是否可以在不影响关注点/抽象分离的情况下合并我的任何重复代码。

就我的基本编程习惯而言，我喜欢首先编写条件(如果否则切换大小写等)；测试它们，然后用代码填充条件并再次测试。请记住，在单元测试中没有必须这样做的规则。我把这称为低级的东西。一旦我的底层工作完成，我将重用代码或将其重构到应用程序的另一个部分，但不是在非常彻底地测试它之后。重复/重构测试糟糕的代码的问题是，如果它坏了，你必须在多个地方修复它。

对我来说，BDD是TDD的自然延续。一旦我的代码库经过了良好的测试，我就可以通过移动整个代码块来轻松地调整行为。关于我的编程习惯，很酷的一点是，有时我会移动代码，发现一些我甚至不想要的有用行为。它有时甚至对重塑品牌很有用，让它看起来像一个完全不同的代码库。

为此，我的代码库在开始时往往会有点慢，并且会加快速度，因为随着开发接近尾声，我有越来越多的代码需要重构或重用。

我编写代码的方式对我的好处是，我能够承担非常高的复杂性，因为这是由良好的关注点分离推动的。对于编写高度优化的代码来说，它也是非常棒的。然而，经过良好优化的代码往往会有点臃肿，但据我所知，没有办法写出没有一点臃肿的优化代码。如果这个应用程序不需要很高的处理器效率，没有什么能阻止我去膨胀我的代码。我的观点是服务器端代码应该优化，而大多数客户端代码通常不需要优化。

回到测试框架的主题，我使用它们只是为了节省一点编译器时间。

就下面的故事板而言，这对我来说是自然而然的，实际上并没有考虑它。我注意到，大多数开发人员都是按照故事板的自然顺序开发的，即使它们不可用时也是如此。

作为一般的关注点分离策略，在大多数应用程序中，我根据UI表单来分离关注点。例如，我将在表单中重用代码，并在表单之间重复/重构。这只是一个概括性的规则。有时候我不得不跳出框框去思考。有时，重复代码可以很好地提高代码处理器的效率。

作为我的TDD习惯的一个小补充，我最后做了优化和容错。我将尽量避免使用try catch块，并以不需要它们的方式编写代码。例如，我不会捕获null，而是检查null，或者不是捕获超出界限的索引，而是仔细检查代码，使其永远不会发生。我发现在应用程序开发中过早地捕获错误会导致语义错误(不会导致应用程序崩溃的行为错误)。语义错误可能很难追踪，甚至很难注意到。这就是我的10美分。希望能有所帮助。