好的测试会导致草率的编码吗？
假设您正在编码，并且遇到了简单代码重用的机会（例如，将一段公共代码提取到可访问的位置，例如实用程序类或基类）。您可能会发现自己在想，“我知道这样做很好，但我现在必须完成这件事，如果我需要更改此代码，并且忘记在其他地方，我的测试框架会让我知道。”
换句话说，您让您（或其他开发人员）编写的出色测试来提醒您也更改其他地方的代码。
这是我们可能在自己或其他开发人员身上发现的合理问题吗？
Let's say you're coding, and you come across an opportunity for simple code resuse (e.g. pulling a common piece of code out to an accessible place like a Utility class or base class). You might find yourself thinking, "I know it's good to do this, but I have to get this done now, and if I need to make a change to this code, and forget to change it in the other place, my testing framework will let me know."
In other words, you let the awesome tests you (or another developer) has written to remind you to change the code in the other places too.
Is this a legitimate problem that we might find in ourselves or other developers?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
您问单元测试是否鼓励您依赖它们作为 TODO 列表的方法？是的，但我不认为这是草率的编码。毕竟，您要从单元测试失败开始，然后编写测试代码；如果你重构一些代码，然后再次编写代码进行测试，那么这并不是草率的编码——它正在做你应该做的事情。
我认为单元测试的问题很简单，就是你无法在单元测试中涵盖所有极端情况，有时人们认为工作测试意味着工作应用程序，但事实并非如此。
You're asking whether unit tests encourage you to rely on them as a method of TODO list? Yes, but I don't think that's sloppy coding. You are, afterall, to start with unit tests failing and code to the test; if you refactor some code and then once again code to the test, that isn't sloppy coding -- it's doing what you're supposed to.
I think the problem with unit tests is simply that you can't cover every corner case in a unit test, and sometimes people assume that a working test means a working app, which isn't true.
在您提供的示例中，良好的测试实际上使您能够实现草率的设计，但是根据我的经验，糟糕的测试不会阻止您这样做。
你的论点中的谬误集中在这样一个前提上：“现在就完成这件事”意味着你可以通过实施草率的设计来节省时间。事实是，无论你的测试好坏，你都在承担技术债务。现在，对该代码进行更改是一项更加复杂的任务，无论您是否有良好的测试框架来提醒您这一点。
良好测试实践的优势可能在于允许您承担某些债务安全级别。只要您继续意识到，由于您的选择，这部分代码现在很薄弱，那么这种权衡可能是值得的——您更快地交付产品，但代价是更高的债务、更低的成本。因此，短期内存在出现错误的风险。
In the example you provide, good tests are in fact enabling you to implement sloppy design, however in my experience, bad tests wouldn't have discouraged you from doing the same.
The fallacy in your argument centers around the premise that "getting this done now" means you will save time by implementing sloppy design. The truth of the matter is that you are incurring technical debt whether your tests are good or not. Making a change to that code is now a much more complex task, whether you have a good testing framework to remind you of that or not.
The strength of good testing practices may be in allowing you to incur that debt with some level of safety. As long as you continue to be aware that this area of the code is now weak, as a result of your choices, then it may be worth the tradeoff -- you ship your product sooner, at the cost of higher debt, with a lower risk of incurring bugs in the short run as a result.
如果测试良好并且代码（草率或其他）通过了测试，那么一切都很好。拥有好的代码固然很好，但是草率的工作代码比好的损坏的代码更好。
If the tests are good and the code (sloppy or otherwise) pass them, all is good. It would be nice to have good code but sloppy working code is better than good broken code.
我不使用测试作为查找需要更改的代码的第一选择。我将使用 IDE 的搜索（或重构）功能并查找调用相关方法的所有位置。
这些测试只是一个很好的补充，以防我不小心马虎或意外引入错误。测试不会让我从一开始就马虎，他们只会在我认为我已经完成时让我放心。
I don't use tests as my first option to finding the code that needs changes. I'll use my IDE's search (or refactoring) functionality and look for all the places that call the method in question.
The tests are just a nice addition in case I was accidentally sloppy or accidentally introduced a bug. Test don't make me sloppy from the start, they just reassure me once I think I'm done.
我想说，好的测试可以让你修复草率的编码。
I would say that good tests enable you to fix sloppy coding.
无论是否进行测试，您都可以编写出极其草率的代码。单元测试使得摆脱它变得稍微容易一些，但只是在短期内。
You can certainly write incredibly sloppy code with or without tests. Unit testing makes it slightly easier to get away with it, but only in the short run.
如果您在代码中的两个位置复制了一组逻辑（在我看来，这是开发人员可以做的最糟糕的事情），那么您可能也会有不一致的测试。
任何程序员能做的最重要的工作就是无情地重构代码，消除所有重复。即使是单次迭代，这几乎总是显示出好处。
为什么你会认为如果你在复制的代码中有两个地方有错误，你的测试会更好？
If you have a set of logic copied in two places in your code (IMO the worst thing a developer can do), then you probably have inconsistent tests as well.
The most important job any programmer can do is ruthlessly refactor the code, removing ALL duplication. This almost always shows benefits on even a single iteration.
Why would you think if you had an error in copied code in 2 places that your tests would be any better?
对我来说，这听起来更像是草率的开发人员和草率的编码实践导致了您的示例中的草率代码。您描述的测试将防止草率的代码走得太远。
It sounds more to me like sloppy developers and sloppy coding practices are what are leading to sloppy code in your example. The tests you described would prevent the sloppy code from ever getting to far.