Getting Started With Unit Testing
菜鸟的菜鸟翻译sdlkfj5首先声明，我只是想每天抽出一点时间练习英语，不想这样荒废了，试着自己翻译点东西，希望大家能给与指正，请不要笑话我
希望能对大家有小小的帮助，也能得到大家的帮助，我没看过中文版，懒得搜了，如果大家谁有，也希望能传我一份，谢谢:-)
这是我中午一小时的“成果”，不过看来是比以前差多了，速度也好慢，真汗！！！希望能提高自己
Introduction
作为项目管理你有管理完成的代码的质量的最终责任吗，但是老实说，你没有真正意识到质量是什么，是吗？你的开发人员是否强烈建议你代码需要重构，而为了避免争论已经完成的代码你必须说“不”？你曾经害怕过一些特殊的开发人员离开项目吗，因为只有他们了解代码工作的重要部分？阅读并找出单元测试如何在你的项目的实际过程中指出明路以及如何预防关于你的开发人员的瓶颈（翻译这句话的时候感觉别扭）。
作为开发者，有时候你是否感到迫切需要重构代码，但是你又害怕接触它，甚至惧怕破坏（break it,怎么翻译？）无论今后，对于有关你希望永远不要再接触的代码的无聊的争论你是否感到头疼？阅读并学习如何提高你的代码质量以及如何改变代码而不需要破坏它们。
-------------------------------01-17-200713:23-------------------坚持的分隔线，不知这次能有多久:-P--------------
What is Unit-Testing
单元测试是功能单元的测试（A unit test is a test of a distinct unit of functionality）。一个功能单元并不直接依赖于其他已经功能单元的完成。在Java应用中，一个功能单元通常是（但并不总是）一个单独的方法。在测试中单元测试粒度是最合适的。
建立单元测试对时间问题的考虑，有时候甚至比功能单元的创建考虑还要多。考虑到效果（？To justify effort），单元测试应该加上把代码质量和重用性。最后，单元测试应该是在相同的时间交付更多的功能或者在更短的时间交付相同的功能。由于设计的重要性和在开周期中早期发现的代码错误，上述功能大多通过单元测试减少集成和验收测试的影响来实现。对上述的学习，将避免开发者对于一个错误重蹈覆辙。
理想情况下，通过接受测试就有能力验证系统是否符合规范，没有代码错误引起的隐患和???（Ideally during acceptance testing one can suffice with verifying that the system meets the specifications without being hindered，let alone frustrated by coding errors）。
在实际应用中，对于一个特定的工程，验证它十分困难甚至是不可能的（In practice, this is very hard if not impossible to prove for one specific project）。然而，有强烈的暗示表明单元测试的有效方法就是验证它。有效的单元测试方法由以下组成：
应用test-first 原则，
使用测试框架和自动测试。
在接下来的3节中将解释如何提高单元测试效率。
---------------------01-19-200712:56~13:40-------------------坚持的分隔线，不知这次能有多久:-P--------------
Test-First 原则
Test-First原则意思是要在开发实际代码前编写测试。在实际应用中，你编写一点测试，再写一些代码，如此循环。像这样运行：
首先你编写一个测试调用并不存在的方法。为什么你要做类似那样的傻事？好吧，当你编写测试时，你必须考虑你需要提供的参数以及方法应该返回什么样的结果。
假设你想写一个用其他字符串代替某个字符串的substitute()方法。这个方法的测试如下：
Public static void testSubstitute() {
AssertEquals(“a bear”, StringUtils.substitute(“a goose”, ”goose”, “bear”));
}
编译这个测试当然会失败，因为方法substitute()根本不存在。所以，下一步就是编写一个方法，使其具有适合的名称?（signature）以及返回一个值，以使测试运行。开始你可以返回一个hard-coded值：（注：这是什么值啊？）
Public static String substitute(String text, String replace, String by) {
Return new String (“a donkey”);
}
当你运行这个测试时将会失败，因为你期望返回”a bear ”，而不是”a donkey”。验证测试时否工作，让它至少失败一次总是件好事。（It is always good to let the test fail at least once, to validate it actually works）.
现在改变测试返回值以使测试运行成功。
Public static String substitute(String text, String replace, String by) {
Return new String (“a bear”);
}
从现在开始，你可以验证你写的每一步而无需破坏？（break怎么翻译）substitute()方法的代码！
接下来用一些代码代替hard-codeed返回值，真正意义上的用’with’参数代替’replace’参数从而代替所有发生在实际中的情况。(The next step would be to replace the hard-coded return value by some code that actually replaces all occurrences of the ‘replace’ parameter by the ‘with’ parameter.)。你通常添加一些像那样的额外测试，用以断言不仅在开始并且所有事件均被代替，以及断言null参数是否被适当处理。你添加的每个测试用例都被立即执行。当测试失败时，你需要调整代码直到运行成功。如此循环。
---------------------01-23-200712:56~13:40-------------------坚持的分隔线，不知这次能有多久:-P--------------
有些人认为test-first和test-driven development不同（另一些人则认为它们是同一个，是相同的），test-first是test-driven development的“极限”形式。Test-driven development涉及到代码与测试同时写。不管怎样，无论你怎么叫它，以何种方式，你都有可能发现它对你写代码方式的影响。如果你还没有这么做，你可能发现你将根据更为清晰的功能以及更为清晰的接口创建更小的方法。无论何时需要，你都可能写出能用单元测试的代码。
---------------------01-24-200712:10~13:25-------------------坚持的分隔线，不知这次能有多久:-P--------------
同时，大多数应用将由很多方法组成，对于这些方法会写更多的测试用例。为了验证在代码中那种改变不会破坏应用，所有的测试必须以一个规则库运行。与必须一个接一个的运行测试相比，人们更愿意可以运行测试集。当一个断言失败时，其他测试需要继续运行。最后，无论如何，必须提供关于什么断言失败的清晰的反馈。
这是一个单元测试框架执行的地方。一个好的测试框架至少提供以下功能。
基于多种对象类型的方便的断言方法。
随时运行任何测试的能力，用以支持bug修复和再现。
创建测试集的能力，测试集由能够一起运行的测试集合组成。
一个友好的用户界面用以观察所有执行的测试。当一个或多个测试失败时，将给出提示。
为任何规模的应用作单元测试，唯一实用的方法就是通过使用单元测试框架。（The only practical way of doing unit-testing for an application of any significant size, is by using a unit-testing framework.）
自动化测试
对于大规模的应用（For applications of a significant size），人们将很快意识到单元测试自动化的必要性。这就意味，所有的测试基于一个规则库自动运行并且记录结果以便日后检查(the results are logged to be reviewed afterwards)。开发者必须更加约束自己为他们创建或修改的代码以及其它直接受到影响的代码运行单元测试。在规则区间（At regular intervals）如果所有测试成功运行将被自动验证。如果没有，第一个行动是修复代码或者测试（无论哪个引起的问题）。这样，自动单元测试提供一种安全网，因此可以帮助发现新的或者改变的代码中未预料到的负作用以及在早期发现bug。
最简单的形式是，单元测试自动化通过创建测试集的层次实现，通过顶部的一个或仅仅一些可以自动运行以及运行所有单元测试的测试集。（In it’s most simple form, unit-testing is automated by creating a hierarchy of test suites, with one or only a few test suites at the top that can be run automatically and that run all unit tests.）
自动化这些测试。在晚上运行所有的测试在第二天开始修改失败的测试。
[ 本帖最后由 dola 于 2007-2-6 18:05 编辑 ]
有几句话不大会翻译，有谁愿意帮帮忙？
有几句话不大会翻译，有谁愿意帮帮忙，小女子谢过了sdlkfj51.A unit test is a test of a distinct unit of functionality.
2.To justify effort
3.Ideally during acceptance testing one can suffice with verifying that the system meets the specifications without being hindered，let alone frustrated by coding errors
4.In practice, this is very hard if not impossible to prove for one specific project 1.一个单元的测试是指针对功能性明显的单元的测试
2.来判定效果
4.实际应用中，即使在可能的情况下，对一个特定工程的证明也是十分困难的
也不知道翻译得对不对，只是写了下我自己的理解拉，第三句太复杂了就没有翻译。嘿嘿
谢谢了
但我感觉第4句应该是对于一个特定的工程，即使有可能，要证明上述理论也是十分困难的我的断句是this is very hard if not impossible to prove
后面的for one specific project单独一块算是定语把
你说呢？ 1. 单元测试是指对函数模块的不同的单元进行测试；
2. 判断付出的努力（看具体的语境）；
3,4句的语法本身有问题.
求助，不会译了
1。Test-First 测试优先？2。signature 名称？
3。hard-coded value 这个怎么译？
4。It is always good to let the test fail at least once, to validate it actually works。 验证测试时否工作，让它至少失败一次总是件好事？
5。break your code 破坏代码？？
6。The next step would be to replace the hard-coded return value by some code that actually replaces all occurrences of the ‘replace’ parameter by the ‘with’ parameter.
接下来用一些代码代替hard-codeed返回值，真正意义上的用’with’参数代替’replace’参数从而代替所有发生在实际中的情况？？？
以上几句应该怎么译比较好？ 1.A unit test is a test of a distinct unit of functionality.
2.To justify effort
3.Ideally during acceptance testing one can suffice with verifying that the system meets the specifications without being hindered，let alone frustrated by coding errors
4.In practice, this is very hard if not impossible to prove for one specific project
1.一次单元测试是对某个特定单元的功能的测试。
2.确定功效。
3.验收测试过程中，理想情况是，能证明系统符合规格，没有拥塞，更没有代码错误的困惑。
4.在实际操作中，如果不能验证某个具体项目的话，进行单元测试会十分困难。 谢谢 谢谢
----02-06-2007 16:40~17:48------------坚持的分隔线，不知这次能有多久:-P-----
单元测试框架JUnit
对于Java，实际测试框架是JUnit（开源）。如果你有OTN账户（When you have an account on OTN?），通过菜单：Help->Check for Updates->check the Junit Extension->next, 你可以很容易得将JUnit集成到JDeveloper中。它将自动下载JUnit插件文件到你的\jdev\lib\ext 目录下（在Oracle JDeveloper 10.1.2及以前的版本中）。你也可以从http://www.junit.org上下载单机版。JUnit 提供上述提到的所有特性，并且可以测试在JVM客户端运行的Java类。使用插件，你可以很容易得创建单元测试（看下面的图示）。你也可以创建一组可以重用的测试集，稍后将会讨论。当你想要遵循测试优先的规则时，在写实际代码前，你应该在为方法定义完名称后，随即为其创建测试桩。代码示例中，在文档的结尾将给出一个使用JUnit的详细的例子。
Mock Objects
许多代码依赖于其他软件组件的存在，对于这些组件，在复杂的系统中建立单元测试结果。（There is a lot of code that depends on the existence of other software components, for which making a unit test results in a complex setup.）考虑到持续代码需要连接数据库，或是代码只不过不运行在客户JVM上，像处理HTTP请求和应答的servlets，再或者EJB远程接口需要连接到远程服务器上。对于某种扩展，你可以通过使用被称为Mock Objects的阻止运行远程上下文的需要（To a certain extend you can prevent the need to run in a broader context by making use of so-called Mock Objects）。例如，你可以使用像数据库对象行为的mock 对象代替建立数据库连接和来自数据库的分支对象。你可以从http://www.mockobjects.com(开源)上下载开发和使用mock对象的特定的框架。
[ 本帖最后由 dola 于 2007-2-6 18:08 编辑 ]
页:
[1]
