需要有关 Junit 入门的建议
我之前没有使用过Junit,也没有自动做过单元测试。
场景: 我们正在将后端 DAO 从 Sql Server 更改为 Oracle。所以在DB端所有的存储过程都被转换为oracle。现在,当我们的代码调用这些 Oracle 存储过程时,我们希望确保返回的数据与 sql server 存储过程相同。
例如,我在 DAO 中有以下方法:
//this is old method. gets data from sql server
public IdentifierBean getHeadIdentifiers_old(String head){
HashMap parmMap = new HashMap();
parmMap.put("head", head);
List result = getSqlMapClientTemplate().queryForList("Income.getIdentifiers", parmMap);
return (IdentifierBean)result.get(0);
}
//this is new method. gets data from Oracle
public IdentifierBean getHeadIdentifiers(String head){
HashMap parmMap = new HashMap();
parmMap.put("head", head);
getSqlMapClientTemplate().queryForObject("Income.getIdentifiers", parmMap);
return (IdentifierBean)((List)parmMap.get("Result0")).get(0);
}
现在我想编写一个 Junit 测试方法,该方法首先调用 getHeadIdentifiers_old,然后调用 getHeadIdentifiers 并比较返回的对象(必须在 IdentifierBean 中覆盖 equals 和 hash)。仅当两个对象相同时测试才会通过。
在测试器方法中,我必须为这两种方法提供一个参数(在本例中为 head)。目前这将手动完成。是的,前端参数可能不同,SP 可能不会返回这些参数的准确结果。但我认为拥有这些测试用例会让我们松一口气,因为它们返回相同的数据......
我的问题是:
- 这是一个好方法吗?
- 我将有多个 DAO。我写吗 DAO 内部的测试方法 本身或对于我应该拥有的每个 DAO 一个单独的 JUnit 测试类?
- (可能是n00b问题)所有的 测试用例自动运行?我愿意 不想去前端点击 一堆东西,以便调用 DAO 被触发。
- 当测试进行时我会发现 哪些方法失败了?并为 失败的会告诉我测试结果吗 失败的方法?
- 最后,有什么好的起点吗?任何 教程、展示工作的文章 与朱尼特
I have not used Junit before and have not done unit testing automatically.
Scenario:
We are changing our backend DAO's from Sql Server to Oracle. So on the DB side all the stored procedures were converted to oracle. Now when our code calls these thew Oracle Stored Procedures we want to make sure that the data returned is same as compared to sql server stored procedures.
So for example I have the following method in a DAO:
//this is old method. gets data from sql server
public IdentifierBean getHeadIdentifiers_old(String head){
HashMap parmMap = new HashMap();
parmMap.put("head", head);
List result = getSqlMapClientTemplate().queryForList("Income.getIdentifiers", parmMap);
return (IdentifierBean)result.get(0);
}
//this is new method. gets data from Oracle
public IdentifierBean getHeadIdentifiers(String head){
HashMap parmMap = new HashMap();
parmMap.put("head", head);
getSqlMapClientTemplate().queryForObject("Income.getIdentifiers", parmMap);
return (IdentifierBean)((List)parmMap.get("Result0")).get(0);
}
now I want to write a Junit test method that would first call getHeadIdentifiers_old
and then getHeadIdentifiers
and would compare the Object returned (will have to over-write equals and hash in IdentifierBean
). Test would pass only when both objects are same.
In the tester method I will have to provide a parameter (head in this case) for the two methods..this will be done manually for now. Yeah, from the front end parameters could be different and SPs might not return exact results for those parameters. But I think having these test cases will give us some relief that they return same data...
My questions are:
- Is this a good approach?
- I will have multiple DAO's. Do I write
the test methods inside the DAO
itself or for each DAO I should have
a seperate JUnit Test Class? - (might be n00b question) will all the
test cases be ran automatically? I do
not want to go to the front end click
bunch of stuff so that call to the
DAO gets triggered. - when tests are ran will I find out
which methods failed? and for the
ones failed will it tell me the test
method that failed? - lastly, any good starting points? any
tutorials, articles that show working
with Junit
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
好吧,让我们看看能做什么......
并不真地。由于您现在拥有两条具有不平等且不可预测功能的代码路径,而不是具有某种已知功能的过时代码路径。通常,人们会首先为遗留代码创建彻底的单元测试,然后重构原始方法,以避免难以置信的大量重构——如果构成庞大应用程序的代码丛林中的某些部分不断调用另一个方法,而其他部分则调用另一个方法,该怎么办?新的?
然而,使用遗留代码从来都不是最佳的,所以您所想到的可能是最好的解决方案。
假设您已经对程序结构进行了正确的面向对象,其中每个类只做一件事并且只做一件事,是的,您应该创建另一个包含该单独类的测试用例的类。你在这里寻找的是模拟对象(一般在SO和Google上搜索它,有很多可用的信息),它可以帮助你将被测试的类与其他类解耦。有趣的是,单元测试中的大量模拟通常意味着您的类可以使用一些大量的重构。
所有 IDE:都允许您同时运行所有 JUnit 测试,例如在 Eclipse 中,只需单击源文件夹/顶部包并选择“运行”->“运行”。联合测试。此外,在运行单个类时,其中包含的所有单元测试都在正确的 JUnit 流程中运行 (
setup()
->testX()
->tearDown( )
)。是的,测试驱动开发的一部分是红绿重构,它指的是 IDE 显示的用于单元测试的彩色条。基本上,如果测试套件中的任何测试失败,则条形图为红色,如果全部通过,则为绿色。此外,对于 JUnit,还有蓝色用于各个测试以显示断言错误。
我很确定答案中很快就会有多个这些内容,请稍等:)
Okay, lets see what can be done...
Not really. Since instead of having one obsolete code path with somewhat known functionality, you now have two code paths with unequal and unpredictable functionality. Usually one would go with creating thorough unit tests for legacy code first and then refactor the original method to avoid incredibly large amounts of refactoring - what if some part of your jungle of codes forming the huge application keeps calling the other method while other parts call the new one?
However working with legacy code is never optimal so what you're thinking may be the best solution.
Assuming you've gone properly OO with your program structure where each class does one thing and one thing only, yes, you should make another class containing the test cases for that individual class. What you're looking for here is mock objects (search for it at SO and Google in general, lots of info available) which help you decouple your class under test from other classes. Interestingly high amount of mocks in unit tests usually mean that your class could use some heavy refactoring.
All IDE:s allow you to run all the JUnit test at the same time, for example in Eclipse just click the source folder/top package and choose Run -> Junit test. Also when running individual class, all the unit tests contained within are run in proper JUnit flow (
setup()
->testX()
->tearDown()
).Yes, part of Test Driven Development is the mantra Red-Green-Refactor which refers to the colored bar shown by IDE:s for unit tests. Basically if any of the tests in test suite fails, the bar is red, if all pass, it's green. Additionally for JUnit there's also blue for individual tests to show assertion errors.
I'm quite sure there's going to be multiple of these in the answers soon, just hang on :)
您将编写一个测试类。
您可能会发现您需要对其进行参数化;这很简单。
更新:看起来像这样:
当然。
为每个 DAO 尝试一个单独的测试类;如果这太乏味,请尝试其他方式,看看你最喜欢什么。拥有单独的测试类的细粒度可能会更有帮助,但您的里程可能会有所不同。
根据您的环境,将有多种方法自动运行所有测试。
是的,是的。
我真的很喜欢 Dave Astels 的书。
You'll write a test class.
You might find you need to parameterize this on head; that's straightforward.
Update: It looks like this:
Sure.
Try it with a separate test class for each DAO; if that gets too tedious, try it the other way and see what you like best. It's probably more helpful to have the fine-grainedness of separate test classes, but your mileage may vary.
Depending on your environment, there will be ways to run all the tests automatically.
Yes and yes.
I really like Dave Astels' book.
编写和维护大型单元测试套件的另一个有用的介绍可能是这本书(部分在线提供):
XUnit 测试模式,《重构测试代码》,作者:Gerard Meszaros
本书分为 3 个主要部分。第一部分由一系列介绍性叙述组成,描述使用 xUnit 进行测试自动化的某些方面。第二部分描述了一些“测试气味”,它们是我们自动化测试方式问题的症状。第三部分包含模式的描述。
Another useful introduction in writing and maintaining large unit test suites might be this book (which is partially available online):
XUnit Test Patterns, Refactoring Test Code by Gerard Meszaros
The book is organized in 3 major parts. Part I consists of a series of introductory narratives that describe some aspect of test automation using xUnit. Part II describes a number of "test smells" that are symptoms of problems with how we are automating our tests. Part III contains descriptions of the patterns.
这是一个快速但相当全面的JUnit 简介。
Here's a quick yet fairly thorough intro to JUnit.