当前位置:首页 > 在JUnit中如果你要测试不同的参数

在JUnit中如果你要测试不同的参数

点击次数:2225  更新日期:2013-03-16
  当我给那些有经验的开发者上课时,我发现只有40%左右的人写测试。大约还有40%的人甚至从来没听说过JUnit,这其中更有一般人完全没有单元测试的概念。开发者通常处于在项目经理制定的紧促计划的压力中——而那些项目经理同样处于客户的压力之下,客户希望他们的软件能够被快速的开发出。不幸的是,测试是项目中的一个重要部分而很多人却轻易的将它砍掉。真是目光短浅,那种做法只会让你的应用成为bug的乐园而且会大大超出你的计划时间。
  为什么会这样?因为写自动测试实际上省下了大量的运行时间。每个开发者都会出错而通过测试可以帮助找到这些错误。可能手工测试在某些方面要比自动测试更快一些,但是手工测试需要用户界面。手工测试的结果并不一致,因为测试者和开发者一样都会犯错。而一个自动测试总会保持结果的一致性。
  也许更重要的是,当一个旧bug被修复或者新特性被添加时会引入更多的bug.你需要在改变系统后重新运行所有的测试。这也是自动测试的价值体现,因为对比手工测试的开销,自动测试的开销是微不足道的。如果开发者经常测试,他们可以更容易地发现并修改问题,这可以保证代码质量并保证团队开发的进度。
  比较JUnit和TestNG——Meera Subbraro
  Martin Fowler曾说过,软件开发领域中此前从没有过这样的事情:很少几行代码对大量的代码起了如此重要的作用。JUnit过去直到如今依然是单元测试的一个标准。它是最流行的开源工具。当然现在我们有许多有别于JUnit的其他的开源工具。我自己,除了使用JUnit外,我还是用TestNG.下面我们来谈谈下这两个框架。
  JUnit和TestNG都使用Annotation,都使得测试简单有趣。如果你写两个测试类,一个使用JUnit一个使用TestNG,除非你看到它们import语句,否则你几乎看不到他们之间的差别。
  如果你是一个TDD的信徒,通过运行测试来完成你的持续集成过程。TestNG可能更加适合。重新运行失败的测试这样的机制对于每天都进行编译来说非常有帮助。而这个特性只有TestNG才有。
  TestNG的另一个亮点是支持参数化。在JUnit中如果你要测试不同的参数,你需要写不同的测试用例来覆盖不同参数。而在TestNG,通过使用xml配置文件做到。开发者可能会抱怨XML文件“这下好了,除了要维护那些测试用例,我还要维护那么一堆xml文件”。(译者按:JUnit4也已经支持参数化测试了)
  JUnit生成的HTML格式的报告非常好。我使用TestNG和Java 6,生成的报告远没有JUnit那么漂亮。
  最后,两个框架都有自己的长处和弱处,必要时我们可以同时使用。让我们使用这两个伟大的框架,享受编写测试的快乐吧。
  我为什么从JUnit换到了TestNG上——Andres Almiray
  当我开始编写测试程序时候,我选择了JUnit3.x.因为那个时候它是唯一的开源选择,而且有着相当详尽的文档和成堆的书供我参考。在此基础上还有许多扩展如dbUnit,xmlUnit帮助测试一些大型组件。但是如果我们需要面对更多复杂的测试,通常是集成/功能测试,很明显JUnit会力不从心。那就是为什么我换到TestNG上。Cedric和Alexandru TestNG的作者从一开始就很明确,TestNG是为更广的测试场合而设计,而不仅是单元测试。TestNG可以运行没有修改过的JUnit测试,这使得两者的转换非常平滑。
  稍后发布的JUnit4.x在细节上非常类似TestNG,这也弥补了这两个框架的裂痕。TestNG仍然是我最喜欢的,而且它仍然保持更新。现在在开源的Java测试框架中仍然有新进者,easyb,一个基于Groovy行为驱动开发的测试工具,为Java和Groovy测试。通过编写合理的测试或是假定一个任务,它可以视为一种规范尽管它是可执行代码。如果你在Ruby世界中使用Rspec一样。
  为什么JUnit仍然是首选——Aslam Khan
  像许多人开始测试驱动开发和单元测试一样,我也是从JUnit3.x起步的。我发现JUnit是最广泛的工具,出现在各种不同的地方(ANT,Maven,Eclipse,IntelliJ IDEA, 等)。它也很容易介绍给那些新团队。我也使用TestNG对它的多样性同样印象深刻。然而,JUnit的大量插件(dbUnit,xmlUnit等)使得Junit仍然是首选的。如果你花大量的时间在Spring上,那么基于Junit的Srping ApplicationContext aware测试用例会带来优势。为了测试前台,我几乎只使用Selenium.我曾经涉足过Canoo和其他的框架,但是发现这些途径都是反TDD模式的。使用Selenium,我可以处理Selenium测试脚本和记录,给任何需要的人并日后处理。
  如果我们谈论的是纯粹的TDD,即书写良好的代码(不仅仅是良好的测试)需要增加一个mock测试。对于mocking,我使用Jmock,它和Junit配合良好,通过基于mock的方式和程序内部边界,我得到了设计良好的,互相通信的对象。这在可读性和可维护性上迈出了重要的一步。EasyMock也不错,但是Jmock是我个人的首选。
  从Java世界上溯到Ruby世界中,RSpec很优秀而且也有DSL来描述场景。既然Rbehave已经融合进了Rspec,这样的整合将成为Ruby世界的首选。有趣的是,Rbehave是从Jbehave衍生来来,它是一个行为驱动开发测试框架。如果你喜欢BDD模式来收集和确定需求,你会喜欢Jbehave和RSpec.\nTAG: \nJava教程\njava教程\nJAVA教程\n\n