使用单元测试指定某个函数返回值所需的时间是一种好习惯。我是单元测试curl函数，并希望指定它需要在5秒后超时。这与单元测试的工作方式一致吗？
答案 0 :(得分：4)
这取决于。如果指定功能在5秒后超时，那么这就是单元测试。我不认为在这样的单元测试中测量性能是一个好主意，因为它增加了太多其他原因导致单元测试失败。如果您在构建服务器上开始在paralel中运行单元测试，则不希望额外的负载导致测试失败。
答案 1 :(得分：2)
测试你的功能加上curl加服务器比单元测试更集成测试。话虽这么说，你不必那么教条，如果你只有一个这样的测试，那肯定是可行的。我写过，并且仍然有不是纯单元测试的测试，但是他们完成了自己的工作。只要他们不妨碍我，我会保留他们。
我唯一感到困扰的是5秒超时，这对于单元测试来说非常长。现在，它取决于它发生的频率。您是否在启动curl之前考虑了基本测试（例如ping服务器）以避免开始不必要的测试。
如果您正在寻找替代方案，那么将测试分为两部分：1 /测试如何调用curl; 2 /测试你的函数对结果的作用？这样你就会与服务器隔离，你不需要任何超时。
答案 2 :(得分：1)
我不认为，这是对方法合同的考验。这就是为什么我会说不，这不是一个单元测试。但这听起来像某种系统测试。
另一个将您的示例视为单元测试的点是事实，它需要很长时间（5秒）才能执行。通常，每次进行更改时，您都应该能够执行完整的单元测试套件。你不能等待很长时间。
这就是为什么我认为你的测试应该在另一组测试中，而不是单元测试。它应该在您的每日构建/持续集成中执行，而不是在每个程序员的每次签入之前执行。
答案 3 :(得分：0)
我认为这可能是一个主观标记，因为你要求的每个人都有自己的单一测试的真正定义。
在我看来，时间超出大多数案例中单元测试的范围，但对于验证超时的正确行为的特定情况，只要执行时间合理，它就是合适的
答案 4 :(得分：0)
纯粹答案：是的，长时间运行的单元测试是代码味道，应该更改
务实的回答：如果您在长时间运行的测试中遇到问题，并且希望确保测试套件快速失败，那么请添加超时。
答案 5 :(得分：0)
我认为你应该嘲笑该函数用来检测它花了足够长时间等待的方法，然后你可以立即测试超时而不是实时等待。
答案 6 :(得分：0)
可能更多是性能测试，但是是的。 nunit有他们：http://weblogs.asp.net/egarmon/archive/2005/02/14/372114.aspx。 junitperf有他们：http://clarkware.com/software/JUnitPerf.html
答案 7 :(得分：0)
如果答案是否定的，该怎么办？这是否意味着你不会写测试？
如果是特殊情况，我会写测试，现在担心。
如果我盯着进行大量涉及计时的测试，我可能会将它们从正常的单元测试中分离出来，以便我可以独立或一起运行这些集合。