我理解单元测试的概念，即提出关于代码应该输出什么的简单想法 - 然后输出它。所以它正在考虑你想要一段代码做什么 - 然后做一个测试以确保它有效。
在学习编程的哪个阶段应该整合TDD（单元测试）？
编辑：一旦完成它的工具停止变得神奇，我就喜欢关于单元测试的评论。
最初的问题是因为我意识到我还没有开发大型程序的技能，但想通过提出一些代码可能/应该做的事情来学习。
我想通过实践来学习，我认为这样做的结构化方法会有所帮助。 Python是我正在使用的语言。感谢到目前为止的所有输入。
答案 0 :(得分：7)
尽早。采用TDD的所有障碍都是因为我不得不打破旧习惯，改变我的思维方式。如果我从一开始就考虑TDD，我会发现整个事情要容易得多。
答案 1 :(得分：7)
当你开始时，单元测试可以节省大量时间，因为你在学习的过程中最终会做很多“代码，运行，调试”循环。这是“运行”阶段，当你每次都特意做这件事时，这个阶段变得很糟糕。另外我认为初学者倾向于引入更多的回归问题，如果你没有立即通过单元测试来抓住它们，这又是一个巨大的时间问题。
答案 2 :(得分：4)
作为旁注，TDD和/或单元测试可以在学习中很晚 处理。即使是经验丰富的程序员也可以在开始使用新语言或新API时获得学习测试。
Kent Beck在其“红色条形图”中以“Learning test”名称推荐此项 “在测试驱动开发中的模式：通过示例。
而不是仅使用新方法或 一个新课，我们写一点测试 验证API是否按预期工作。
同样，Mike Clark在learning Ruby期间编写了一套400多个测试。
编写学习测试是一种有趣的方式 戳和推动任何新语言或API。 每次测试都是你写的 投资可执行知识 基
答案 3 :(得分：2)
我们是在谈论学习新语言的新手还是程序员？如果后者 - 我会说，马上。 为什么？因为最好的学习方法是编写代码，如果编写代码则应该进行测试。 然而，没有编程概念的人应该首先学习编程的基础知识
答案 4 :(得分：2)
一般来说，测试应该作为IMO编程的第一门课程的一部分进行教学。单元测试不一定是我接近开头的东西，因为什么是或不是“单元”的想法很容易成为语义和哲学。将测试类型指定为单元测试我可以在第二或第三课程中看到。当然，我不记得在大学学习单元测试，所以不知何故它没有进入我90年代回到学校的课程。
在获得测试的基本思想后，很快就可以使用TDD作为一种哲学。我不确定我是否想要与那些不知道代码是什么的人进行所有不同类型的测试。一旦有人掌握了一些编程基础知识，那么测试将成为一种有用的方式来表明，“是的，这个程序确实做了它必须做的事情。”尝试TDD的学生如果对编程仍然相对较新，可能会认为它是简单而自然的，而那些已编程多年的学生可能很难适应范式。答案 5 :(得分：1)
如果我在开发过程中作为程序员使用过单元测试和TDD，那么我坚信我可以更快地生成质量更好的代码（不是说我当时的代码完全是废话：）
答案 6 :(得分：1)
当然这是一个非常主观的问题，但我认为我们当然可以对其进行早期限制。我会说在单元测试框架的操作停止看似不像魔术之前。所以在Java中，使用JUnit，您需要首先了解异常，方法，返回值，参数，基本运算符等。
部分问题在于许多简单的编程示例都要求用户输入，这很难进行单元测试，因此您不希望在早期做出太大的障碍，但如果单元测试通常是尽早完成，然后可能更容易对需要执行此操作的代码进行单元测试。
答案 7 :(得分：1)
我认为使用TDD（或者希望与TDD一起工作）所需的范式（思维上的转变）就是通过对程序员花费时间和增加价值的“整体”观点来看待它。纯粹的敏捷/ scrum实践经过培训，只有当它正确地实现了目标（转换某些东西等）时才能看到一段代码具有正值（并算作“完成”）。这是因为我们只是在愚弄价值（可接受性），除非它是正确的。
定义测试结构首先定义编码的目标以及它可能出错的地方（边缘和负面测试用例）。此外，检查目标是否实现是自动化的。
答案 8 :(得分：1)
我猜您的单元测试概念不正确。从技术上讲，“单元测试”是一种软件验证和验证方法，程序员在其中测试各个源代码单元是否适合使用。单元是应用程序中最小的可测试部分。在过程编程中，单元可以是单独的函数或过程，在面向对象的编程中，它可以是类的方法。
你想要做的基本上是“先做小程序，然后逐渐使它们复杂化（在课程中你将最终学习编程）”。这种类型的软件开发“从简单开始然后逐渐复杂化”在技术上被称为“软件原型”。以下是它的定义：
“软件原型设计是某些软件开发过程中的一项活动，是原型的创建，即正在开发的软件程序的不完整版本。 原型通常仅模拟最终程序的特征的几个方面，并且可能与最终实现完全不同。 原型的传统目的是允许软件的用户通过实际尝试来评估开发人员对最终产品设计的建议，而不是必须基于描述来解释和评估设计。最终用户也可以使用原型来描述和证明开发人员未考虑的要求，因此“控制原型”可能是解决方案提供商与其客户之间商业关系的关键因素。“
另一方面，单元测试只是“软件测试”中的方法之一。它不是软件开发的一部分。最后在创建相当大的程序时完成，并确保每个部分（即较小的单元，如函数，过程，类方法等）正常工作。单元测试不能用于软件开发的基础，因为最后如果单元测试导致“任何一件都有错误”，它肯定意味着整个软件是错误的，而如果单元测试说“所有部件都没有错误，那就没有” t意味着整个软件没有错误“因为在集成这些部分时可能会有一些错误，或者单元测试无法捕获程序中的每个错误：除了最琐碎的程序之外，不可能评估所有执行路径。单元测试也是如此。此外，根据定义，单元测试仅测试单元本身的功能。因此，它不会捕获集成错误或更广泛的系统级错误（例如跨多个单元执行的功能，或性能等非功能测试区域）。单元测试必须与其他软件测试活动一起完成。像所有形式的软件测试一样，单元测试只能显示错误的存在;他们无法证明没有错误。
要从单元测试中获得预期的好处，整个软件开发过程都需要严格的规范。必须不仅要仔细记录已执行的测试，还要记录对软件中此部件或任何其他部件的源代码所做的所有更改。使用版本控制系统至关重要。如果该单元的更高版本未通过之前通过的特定测试，则版本控制软件可以提供自该时间以来已应用于该单元的源代码更改列表（如果有）。
实施可持续流程以确保每天审核测试用例失败并立即解决问题也很重要。如果这样的过程没有实现并且根深蒂固到团队的工作流程中，那么应用程序将与单元测试套件不同步，增加误报并降低测试套件的有效性。
我希望你现在对“单元测试”这个术语有了更好的理解。你想要做的是通过“软件原型设计”来学习。那么，就学习而言，你可以选择任何方式，即。 a）在编写代码之前阅读很多程序 b）只需阅读一些编程语言的基础知识，然后开始创建更简单的程序，然后再用增加的知识使它们变得复杂。
选项（a）花费较少的时间让您走上专家的道路，并且采用您在“自学习编程”期间可能出现的错误做法的机会较少
选项（b）需要更多的时间来引导专家的方式，但可能你可能会设计自己的编程风格，并且可能会变得与其他专家的编程风格一样好（如果不是更好）。
我建议不要只选择上述选项（a）或（b）中的一种方式。使用两种方式并从选项（a）开始。
快乐编程！欢迎来到疯狂社区！
答案 9 :(得分：1)
我认为进行单元测试更多的是学习良好的设计实践而不是一般的编程。我发现当你同时编写单元测试时，你倾向于设计更好的组件，并在它们之间建立更清晰的接口。
答案 10 :(得分：1)
特别是考虑到上下文 - Python单元测试非常容易编写并且需要很少的理解 - 我会说去吧并用测试覆盖你的理解和探索。
在您这样做了一段时间之后，请包含一个评论阶段，您可以返回并阅读之前的测试，看看如何根据您当前的理解重写它们。这就是评论的意思 - 在每个测试定义的文档字符串中为自己编写问题和评论笔记。
使用这种增量方法，使用版本控制将有助于审阅并且我高度推荐它，特别是因为您将能够从版本控制日志中查看更改的历史记录，从而通过您的可见性获得更多自我鼓励进展。我推荐使用git并在Macinosh上使用内置的gitgui或GitX。
作为一名非常有经验的专业人士，我早于单元测试概念，但我当然使用了大量的小测试来学习新的库和语言。
答案 11 :(得分：1)
在我看来，它是一个巨大而有力的学习工具。我用来学习javascript和python，并且有很好的结果。
我不是在谈论单元测试，我在谈论使用babysteps，红绿色重构......所有那些将学习过程变为轻松过程的实践。
所以我尝试从小块开始，做假人的东西，并且我将使用语言的硬件来增加难度。
然后我注意到我最终写了一个优秀的后验研究来源，所以如果我有任何疑问，我会回到我的tddlearn并解决它，或者如果我找到了更好的方法来做某些事情或发现了限制，我为它编写测试......
太棒了!!!
您可以查看我的进度here
答案 12 :(得分：1)
无法相信没人提到katas：
https://github.com/gamontalvo/awesome-katas
和类似的公案：
https://github.com/ts25504/awesome-koans
这两个概念都是通过编写和执行测试来自学，直到它们通过。
TDD从上到下的方法实际上非常类似于基本的学术方法;首先引入一个主题，通常是一个推定，然后深入研究具体细节