我一直在项目中说明它需要做TDD,但大多数测试是以某种方式集成测试或在项目期间TDD被遗忘,努力完成代码更快。
所以,就我的情况来说,我有书面单元测试,但我发现自己将开始编写代码,而不是编写测试。我觉得有一个思想/设计/范式的变化,这是巨大的。所以,虽然一个真正相信TDD,你实际上最终回到旧风格,因为时间压力/项目可交付成果。
我有几个类,我有纯单元测试代码,但我似乎不能继续的过程,当mocks进入图片。另外,我有时看到:“为它写一个测试是不是太微不足道”综合症。
你怎么认为我应该处理这个?
TDD实际上体现了这一点。
要写一个测试,你首先必须知道 – 用非常简单的术语 – 你的输入将是什么,你期望的输出将是什么。
一旦你有了这些知识,你可以编写一个测试来练习一些神话代码,以及在一定程度上,在编写代码本身或创建这些工件之前,代码将与之交互的其他工件。
这就是我们以前在“瀑布”方法中称为“需求工程”和“系统分析”。
除此之外,你会发现,一旦你掌握了这个级别的需求,写测试就会自然而然地发生(毕竟,它只是那些需求中体现的功能语句的代码中的表达式)。
在编写以测试形式表达需求的代码时,在以可执行代码的形式向项目提交这些空白和误解之前,您将找出需求中的差距和误解。
对于“敏捷”的现代从业者,承认他们从事一系列“瀑布”的方法,我认为太尴尬了,所以这需要工程和理解被混淆在语言背后的需要解决这些事情的语言同时试图拼命地避免承认“敏捷”(通常被理解,或者可能被误解)将婴儿抛出大部分的洗澡水。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。