重构非回归测试时如何保护自己?

发布于 2024-09-25 17:05:13 字数 236 浏览 5 评论 0原文

重构非回归测试时是否需要考虑特定技术?代码通常非常简单,但它显然没有包含在测试套件的安全网中......

当然,在构建非回归测试时,我首先确保它确实表现出我想要纠正的问题。但是,如果我稍后回来进行此测试,因为我想重构它(例如,我刚刚添加了另一个非常相似的测试),我通常无法将测试中的代码恢复到显示第一个问题的状态。因此,我无法确定测试在重构后是否仍在代码中执行相同的路径。

除了格外小心之外,是否有特定的技术可以解决这个问题?

Are there specific techniques to consider when refactoring the non-regression tests? The code is usually pretty simple, but it's obviously not included into the safety net of a test suite...

When building a non-regression test, I first ensure that it really exhibits the issue that I want to correct, of course. But if I come back later to this test because I want to refactor it (e.g. I just added another very similar test), I usually can't put the code-under-test back in a state where it was exhibiting the first issue. So I can't be sure that the test, once refactored, is still exercising the same paths in the code.

Are there specific techniques to deal with this issue, except being extra careful?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

笑,眼淚并存 2024-10-02 17:05:13

这不是什么大问题。测试测试代码,代码测试测试。尽管有可能犯一个笨拙的错误,导致测试在所有情况下都开始通过,但这不太可能。您将一次又一次地运行测试,因此测试和测试的代码会得到大量的练习,当情况变得更糟时,测试通常会开始失败。

当然,要小心;当然,在重构之前和之后立即运行测试。如果您对重构感到不舒服,请以允许您看到测试工作的方式进行重构(通过失败)。在重构之前找到一种可靠的方法来使每个测试失败,并将其写下来。变为绿色 - 所有测试都通过 - 然后重构测试。运行测试;还是绿色的?好的。 (如果没有,当然,也许可以重新开始,变得绿色)。执行导致原始未重构测试失败的更改。红色的?和以前一样失败吗?然后恢复工作代码,并再次检查绿色。检查并继续您的下一个任务。

It's not a big problem. The tests test the code, and the code tests the tests. Although it's possible to make a clumsy mistake that causes the test to start passing under all circumstances, it's not likely. You'll be running the tests again and again, so the tests and the code they test gets a lot of exercise, and when things change for the worse, tests generally start failing.

Of course, be careful; of course, run the tests immediately before and after refactoring. If you're uncomfortable about your refactoring, do it in a way that allows you to see the test working (passing and failing). Find a reliable way to fail each test before the refactoring, and write it down. Get to green - all tests passing - then refactor the test. Run the tests; still green? Good. (If not, of course, get green, perhaps by starting over). Perform the changes that made the original unrefactored tests fail. Red? Same failure as before? Then reinstate the working code, and check for green again. Check it in and move onto your next task.

夏末染殇 2024-10-02 17:05:13

尝试在自动化测试中不仅包含正面案例,还包含负面案例(以及它们的适当处理程序)。

此外,您可以尝试使用断点运行重构的自动化测试,并通过调试器进行监督,确保它继续执行您想要执行的所有路径。

Try to include not only positive cases in your automated test, but also negative cases (and a proper handler for them).

Also, you can try to run your refactored automated test with breakpoints and supervise through the debugger that it keeps on exercising all the paths you intended it to exercise.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文