如何处理 TDD 的重构阶段 [英] How to handle the refactoring phase of TDD

查看:43
本文介绍了如何处理 TDD 的重构阶段的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

在 TDD 会话过程中,假设我编写了一个失败的测试,然后让它通过.我通过从原始单元中提取代码进行重构,使用诸如提取类和移动方法之类的重构.现在进一步假设我的原始测试不再覆盖提取的代码,因为原始代码现在模拟了它的依赖项,这对于单元测试来说是正确的.

In the course of a TDD session, suppose I write a failing test, and then make it pass. I refactor by extracting code out of the original Unit, using refactorings such as Extract Class and Move Method. Now further suppose that my original test no longer covers the extracted code because the original code now mocks out its dependencies, as is correct for a Unit test.

返回并在提取的代码上改进测试是否合适?或者我是否在重构过程中以未经测试的代码结束时犯了一个错误?感觉就像我的代码库正在扩展,我必须重构,我正在重构代码上的大量测试.这感觉真的很别扭.我重构错了吗?

Is it proper to go back and retrofit tests onto the extracted code? Or did I make a mistake in how I ended up with untested code during a refactoring? It feels like as my codebase is scaling, and I have to refactor, I'm retrofitting a lot of tests onto refactored code. This feels really awkward. Am I refactoring wrong?

推荐答案

现在进一步假设我的原始测试不再覆盖提取的代码,因为原始代码现在模拟了它的依赖项,这对于单元测试来说是正确的.

Now further suppose that my original test no longer covers the extracted code because the original code now mocks out its dependencies, as is correct for a Unit test.

模拟依赖项通常是一件好事,但并非总是如此,而且我不会说模拟所有依赖项对于单元测试来说是正确的".

Mocking dependencies is frequently a good thing to do, but not always, and I wouldn't say it's "correct for a unit test" to mock all dependencies.

在 TDD 的重构步骤中,您应该更改生产代码中不影响测试通过的内容.而且您不应该同时更改测试.

In the refactoring step of TDD, you should be changing things in the production code that don't affect the passing of the tests. And you shouldn't be changing the tests at the same time.

您可能希望稍后修改您的测试,以便提取的代码独立于原始代码进行测试,并在原始测试中进行模拟.

You might want to later modify your tests so that the extracted code is tested independently of the original code and is mocked in the original tests.

这篇关于如何处理 TDD 的重构阶段的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆