blocks|key|4864507|text|试着阅读这篇博文：编写伟大的单元测试:最佳和最差的实践。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|4864508|但是网络上还有无数的其他人。|4864509|直接回答你的问题..。|4864510|“正常趋势”--我想这可能会因地而异，对我来说正常的东西对其他人来说可能是奇怪的。|ordered-list-item|4864511|我会说(在我的选择中)编写代码的开发人员应该编写测试，最好使用像TDD这样的方法，在编写代码之前编写测试。但其他人在这里可能有不同的方法和想法！|4864512|你写测试的方式(在你的问题中)是完全错误的！！|entityMap|0|LINK|mutability|MUTABLE|url|http://blog.stevensanderson.com/2009/08/24/writing-great-unit-tests-best-and-worst-practises/^0|9|I|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@$A|W|B|X|1|Y]]|C|$]]|$1|D|3|E|5|6|7|Z|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|10|8|@]|9|@]|C|$]]|$1|H|3|I|5|J|7|11|8|@]|9|@]|C|$]]|$1|K|3|L|5|J|7|12|8|@]|9|@]|C|$]]|$1|M|3|N|5|6|7|13|8|@]|9|@]|C|$]]]|O|$P|$5|Q|R|S|C|$T|U]]]]

Try reading this blog post: <a href="http://blog.stevensanderson.com/2009/08/24/writing-great-unit-tests-best-and-worst-practises/">Writing Great Unit Tests: Best and Worst Practices</a>. 

But there are countless others on the web. 

In direct answer to your questions...

<ol>
<li>"Normal trend" - I guess this could differ from place to place, whats normal for me might be odd for others.</li>
<li>I would say (in my option) the developer who writes the code should write the test, ideally using methods like TDD, where you would write the test before the code. But others may have different methods and ideas here!</li>
</ol>

And the way you described of writing the tests (in your question) is totally wrong!!

blocks|key|1122919|text|这种方法使单元测试变得毫无价值。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1122920|当某些实际操作不按预期工作时，您需要让单元测试失败。如果您不这样做，甚至在测试代码之前编写测试，这就像没有功能的烟雾报警器。|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|E|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|F|8|@]|9|@]|A|$]]]|D|$]]

This approach make the unit test worthless.

You need to have the unit test fail when some real action does not work as intended. If you don't do it like that, and perhaps even write the test before the code to test, it is like having non-functioning smoke alarms.

blocks|key|1123075|text|如果您不知道一个函数做什么，那么您就不能为它编写一个单元测试。据你所知，它甚至没有做它应该做的事。你得先弄清楚它该怎么做。那就写测试吧。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|entityMap^0^^$0|@$1|2|3|4|5|6|7|C|8|@]|9|@]|A|$]]]|B|$]]

If you don't know what a function does then you can't write a unit test for it. For all you know it doesn't even do what it's supposed to. You need to find out what it's supposed to do first. THEN write the test.

blocks|key|1123199|text|在真实世界中，为其他人的代码编写单元测试是非常正常的。当然，最初的开发人员应该已经这样做了，但是通常您会收到遗留代码，而这些代码只是没有完成。顺便说一句，不管遗留代码是几十年前来自遥远星系的，还是你的同事在上周检查过的，或者是你今天写的，遗留代码是没有测试的代码。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1123200|问问自己:为什么我们要写单元测试？“走向绿色”显然只是达到目的的一种手段，最终目标是证明或反驳关于被测试代码的断言。|1123201|假设您有一个计算浮点数平方根的方法。在Java中，接口将其定义为：|1123202|public+double+squareRoot(double+number);|code-block|syntax|javascript|1123203|不管您是编写了实现还是其他人编写了实现，您都希望断言squareRoot的一些属性：|1123204|它可以返回像sqrt这样的简单根(4.0)|ordered-list-item|1123205|它可以找到一个真正的根，比如sqrt(2.0)，达到一个合理的精度|1123206|它发现sqrt(+0.0+)为0.0。|1123207|当输入负数(即在sqrt(-1.0)上)时，它抛出一个IllegalArgumentException。|1123208|所以你开始把这些写成单独的测试：|1123209|@Test
public+void+canFindSimpleRoot()+{
++assertEquals(2,+squareRoot(4),+epsilon);
}|1123210|噢，这个测试已经失败了：|1123211|java.lang.AssertionError:+Use+assertEquals(expected,+actual,+delta)+to+compare+floating-point+numbers|1123212|你忘了浮点运算。好的，您介绍double+epsilon=0.01，然后：|style|CODE|1123213|@Test
public+void+canFindSimpleRootToEpsilonPrecision()+{
++assertEquals(2,+squareRoot(4),+epsilon);
}|1123214|并添加其他测试:最后|1123215|@Test
@ExpectedException(IllegalArgumentException.class)
public+void+throwsExceptionOnNegativeInput()+{
++assertEquals(-1,+squareRoot(-1),+epsilon);
}|1123216|噢，又一次：|1123217|java.lang.AssertionError:+expected:<-1.0>+but+was:<NaN>|1123218|你应该测试：|1123219|@Test
public+void+returnsNaNOnNegativeInput()+{
++assertEquals(Double.NaN,+squareRoot(-1),+epsilon);
}|1123220|我们在这里做了什么？我们从一些关于该方法应该如何运行的假设开始，发现并不是所有的假设都是正确的。然后，我们制作了测试套件Green，以记录证明该方法的行为根据我们纠正的假设。现在，此代码的客户端可以依赖于这种行为。如果有人要用其他东西交换squareRoot的实际实现，例如，一些实际上抛出异常而不是返回NaN的东西，我们的测试将立即捕捉到这一点。|1123221|这个例子很简单，但是通常您继承了大量代码，在这些代码中，不清楚它到底做了什么。在这种情况下，在代码周围放置测试工具是正常的。从一些关于代码应该如何运行的基本假设开始，为它们编写单元测试，测试。如果绿色，很好，写更多的测试。如果是红色，那么现在你有一个失败的断言，你可以坚持一个规范。也许在遗留代码中有个bug。也许规范还不清楚这个特定的输入。也许你没有什么规范。在这种情况下，重写测试，以便记录意外行为：|1123222|@Test
public+void+throwsNoExceptionOnNegativeInput()+{
++assertNotNull(squareRoot(-1));+//+Shouldn't+this+fail?
}|1123223|随着时间的推移，您将得到一个测试工具，用于记录代码的实际行为，并成为一种编码规范。如果您想要更改遗留代码，或将其替换为其他代码，则可以使用测试工具来验证新代码的行为是否相同，或者新代码的行为是否以预期的和受控的方式不同(例如，它实际上修复了您期望它修复的bug+)。这个线束不一定要在第一天就完成，事实上，有一个不完整的线束几乎总是比没有线束更好。拥有一个线束意味着您可以更轻松地编写客户端代码，您知道当您更改某件事情时会在哪里发生故障，以及当它们最终发生故障时，它们会在哪里崩溃。|1123224|你应该试着摆脱这样的心态:你必须编写单元测试，就像你必须在表单上填写强制字段一样。你不应该仅仅为了使红线变绿而编写单元测试。单元测试不是你的敌人，单元测试是你的朋友。|entityMap|0|LINK|mutability|MUTABLE|url|http://www.netobjectives.com/system/files/WorkingEffectivelyWithLegacyCode.pdf^0|3G|7|0|0|0|0|0|0|0|0|0|0|0|0|0|0|E|J|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|24|8|@]|9|@$A|25|B|26|1|27]]|C|$]]|$1|D|3|E|5|6|7|28|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|29|8|@]|9|@]|C|$]]|$1|H|3|I|5|J|7|2A|8|@]|9|@]|C|$K|L]]|$1|M|3|N|5|6|7|2B|8|@]|9|@]|C|$]]|$1|O|3|P|5|Q|7|2C|8|@]|9|@]|C|$]]|$1|R|3|S|5|Q|7|2D|8|@]|9|@]|C|$]]|$1|T|3|U|5|Q|7|2E|8|@]|9|@]|C|$]]|$1|V|3|W|5|Q|7|2F|8|@]|9|@]|C|$]]|$1|X|3|Y|5|6|7|2G|8|@]|9|@]|C|$]]|$1|Z|3|10|5|J|7|2H|8|@]|9|@]|C|$K|L]]|$1|11|3|12|5|6|7|2I|8|@]|9|@]|C|$]]|$1|13|3|14|5|J|7|2J|8|@]|9|@]|C|$K|L]]|$1|15|3|16|5|6|7|2K|8|@$A|2L|B|2M|17|18]]|9|@]|C|$]]|$1|19|3|1A|5|J|7|2N|8|@]|9|@]|C|$K|L]]|$1|1B|3|1C|5|6|7|2O|8|@]|9|@]|C|$]]|$1|1D|3|1E|5|J|7|2P|8|@]|9|@]|C|$K|L]]|$1|1F|3|1G|5|6|7|2Q|8|@]|9|@]|C|$]]|$1|1H|3|1I|5|J|7|2R|8|@]|9|@]|C|$K|L]]|$1|1J|3|1K|5|6|7|2S|8|@]|9|@]|C|$]]|$1|1L|3|1M|5|J|7|2T|8|@]|9|@]|C|$K|L]]|$1|1N|3|1O|5|6|7|2U|8|@]|9|@]|C|$]]|$1|1P|3|1Q|5|6|7|2V|8|@]|9|@]|C|$]]|$1|1R|3|1S|5|J|7|2W|8|@]|9|@]|C|$K|L]]|$1|1T|3|1U|5|6|7|2X|8|@]|9|@]|C|$]]|$1|1V|3|1W|5|6|7|2Y|8|@]|9|@]|C|$]]]|1X|$1Y|$5|1Z|20|21|C|$22|23]]]]

In the Real World, it's perfectly normal to write unit tests for someone else's code. Sure, the original developer should have done this already, but often you receive legacy code where this just wasn't done. By the way, it doesn't matter whether that legacy code came decades ago from a galaxy far, far away, or whether one of your coworkers checked it in last week, or whether you wrote it today, legacy code is <a href="http://www.netobjectives.com/system/files/WorkingEffectivelyWithLegacyCode.pdf" rel="nofollow">code without tests</a>

Ask yourself: why do we write unit tests? Going Green is obviously just a means to an end, the ultimate goal is to prove or disprove assertions about the code under test.

Say you have a method that calculates the square root of a floating-point number. In Java, the interface would define it as:

<pre><code>public double squareRoot(double number);
</code></pre>

It doesn't matter whether you wrote the implementation or whether someone else did, you want to assert a few properties of squareRoot:

<ol>
<li>that it can return simple roots like sqrt(4.0)</li>
<li>that it can find a real root like sqrt(2.0) to a reasonable precision</li>
<li>that it finds that sqrt(0.0) is 0.0</li>
<li>that it throws an IllegalArgumentException when fed a negative number, i.e. on sqrt(-1.0)</li>
</ol>

So you start writing these as individual tests:

<pre><code>@Test
public void canFindSimpleRoot() {
 assertEquals(2, squareRoot(4), epsilon);
}
</code></pre>

Oops, this test already fails:

<pre><code>java.lang.AssertionError: Use assertEquals(expected, actual, delta) to compare floating-point numbers
</code></pre>

You forgot about floating point arithmetic. OK, you introduce <code>double epsilon=0.01</code> and go:

<pre><code>@Test
public void canFindSimpleRootToEpsilonPrecision() {
 assertEquals(2, squareRoot(4), epsilon);
}
</code></pre>

and add the other tests: finally

<pre><code>@Test
@ExpectedException(IllegalArgumentException.class)
public void throwsExceptionOnNegativeInput() {
 assertEquals(-1, squareRoot(-1), epsilon);
}
</code></pre>

and oops, again:

<pre><code>java.lang.AssertionError: expected:&lt;-1.0&gt; but was:&lt;NaN&gt;
</code></pre>

You should have tested:

<pre><code>@Test
public void returnsNaNOnNegativeInput() {
 assertEquals(Double.NaN, squareRoot(-1), epsilon);
}
</code></pre>

What have we done here? We started out with a few assumptions about how the method should behave, and found that not all were true. We then made the test suite Green, to write down proof that the method behaves according to our corrected assumptions. Now clients of this code can rely on this behavior. If someone were to exchange the actual implementation of squareRoot with something else, something that for example really threw an exception instead of returning NaN, our tests would catch this immediately.

This example is trivial, but often you inherit large pieces of code where it's unclear what it actually does. In that case, it is normal to lay a test harness around the code. Start with a few basic assumptions about how the code should behave, write unit tests for them, test. If Green, good, write more tests. If Red, well now you have a failed assertion that you can hold against a spec. Maybe there's a bug in the legacy code. Maybe the spec is unclear about this particular input. Maybe you don't have a spec. In that case, rewrite the test such that it documents the unexpected behaviour:

<pre><code>@Test
public void throwsNoExceptionOnNegativeInput() {
 assertNotNull(squareRoot(-1)); // Shouldn't this fail?
}
</code></pre>

Over time, you end up with a test harness that documents how the code actually behaves, and becomes sort of a coded spec. If you ever want to change the legacy code, or replace it with something else, you have the test harness to verify that the new code behaves the same, or that the new code behaves differently in expected and controlled ways (for example that it actually fixes the bug you expect it to fix). This harness doesn't have to be complete on day one, in fact, having an incomplete harness is almost always better than having no harness at all. Having a harness means you can write your client code with more ease, you know where to expect things to break when you change something, and where they broke when they eventually did.

You should try to get out of the mindset that you have to write unit tests just because you have to, like you would fill out mandatory fields on a form. And you should not write unit tests just to make the red line green. Unit tests are not your enemies, unit tests are your friends.

blocks|key|4864528|text|当我为打印机编写测试用例时，我试着考虑每一个小的components....and，我可以做些什么来打破它。比如说扫描仪，它使用什么命令(在pjl打印机-作业语言中)--现在我可以写什么来测试functionality....Ok的每一个部分--我可以做些什么来尝试打破它呢？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4864529|我试着对每个主要组件都这样做，但是当涉及到软件而不是太多的硬件时，您需要查看每一种方法/功能，检查边界等等。|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|E|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|F|8|@]|9|@]|A|$]]]|D|$]]

When im writing test cases (for printers) I try to think of each little components....and what can I do to possibly break it.
So lets say the scanner for instance, what commands does it use (in the pjl printer-job-language) what can I write to test every bit of functionality....Ok now what can I do to try and break that.

I try to do that for each major components, but when it comes to software and not so much hardware you want to look at each method/function and check boundaries and such.

blocks|key|1123056|text|听起来，您正在与不进行单元测试的其他开发人员(或维护其他开发人员编写的代码)一起工作。在这种情况下，我认为您肯定想知道您正在测试的对象或方法应该做什么，然后为它创建一个测试。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1123057|它不会是TDD，因为您没有首先编写测试，但是您可以改进这种情况。您还可能希望使用存根创建被测试对象的副本，以便在代码失败时确定测试正常运行。|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|E|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|F|8|@]|9|@]|A|$]]]|D|$]]

It sounds like you are working with other developers (or maintaining code written by other developers) who do not do unit testing. In that case, I think you'd definitely want to know what the object or method you're testing is supposed to do, then create a test for it. 

It won't be TDD because you didn't write the test first, but you could improve the situation. You might also want to create a a copy of the objects under test with stubs so that can establish that your tests function properly when the code fails.

Sometimes I end up writing unit test cases for code that other developers have written. There are occasions when I really don't know what the developer is trying to do (the business part) and I just manipulate the test case to get the green line. Are these things normal in the industry? 

What is the normal trend? Are the developers supposed to write unit test cases for code they wrote themselves?

How do you write unit test cases?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

有时，我会为其他开发人员编写的代码编写单元测试用例。在某些情况下，我真的不知道开发人员在做什么(业务部分)，我只是操纵测试用例来获得绿线。这些东西在这个行业里正常吗？正常趋势是什么？开发人员是否应该为他们自己编写的代码编写单元测试用例？

问如何编写单元测试用例？
EN

回答 6

Software Engineering用户

Software Engineering用户

Software Engineering用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何编写单元测试用例？EN

回答 6

Software Engineering用户

Software Engineering用户

Software Engineering用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何编写单元测试用例？
EN