java DTO 的单元测试
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/5116860/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Unit testing of DTOs
提问by Shikarn-O
Is it appropriate and necessary to test getters and setters?
测试 getter 和 setter 是否合适和必要？
I think they haven't any logic and they can't crash or throw any exceptions.
我认为他们没有任何逻辑，他们不能崩溃或抛出任何异常。
回答by Luciano Fiandesio
You should not unit test DTO's getters and setters, unless they contain some complex logic that requires some testing.
你不应该对 DTO 的 getter 和 setter 进行单元测试，除非它们包含一些需要一些测试的复杂逻辑。
回答by Martin R-L
I'm reading GOOSat the moment, and the authors suggest that you don't write test cases for your ?value objects? (e.g. DTO's).
我目前正在阅读GOOS，作者建议您不要为您的 ?value 对象编写测试用例？（例如 DTO）。
Coverage for the coverage's own sake is never good. "Tests should be meaningful", as Karl Seguin puts it.
为了保险本身的缘故，保险从来都不是好的。“测试应该是有意义的”，正如 Karl Seguin 所说。
回答by user666
Using modern tools it's not much of an effort:
使用现代工具并不难：
import static com.google.code.beanmatchers.BeanMatchers.hasValidBeanConstructor;
import static com.google.code.beanmatchers.BeanMatchers.hasValidBeanEquals;
import static com.google.code.beanmatchers.BeanMatchers.hasValidBeanHashCode;
import static com.google.code.beanmatchers.BeanMatchers.hasValidBeanToString;
import static com.google.code.beanmatchers.BeanMatchers.hasValidGettersAndSetters;
import static org.hamcrest.CoreMatchers.allOf;
import static org.hamcrest.MatcherAssert.assertThat;
import static org.junit.Assert.assertNotNull;
public class Test {
@Before
public void setUp() throws Exception {
}
@Test
public void testFlatFileReaderMetadata_Parameters() throws Exception {
assertNotNull(new Test());
assertThat(Test.class, allOf(hasValidBeanConstructor(), hasValidBeanEquals(), hasValidGettersAndSetters(),
hasValidBeanHashCode(), hasValidBeanToString()));
}
}
回答by Tomasz Nurkiewicz
If the code for getters and setters is generated, I would assume it is correct. This is a major drawback of not having properties at language level - you have a lot of generated code that is checked-in into source control and should be tested because it screams red in coverage reports.
如果生成了 getter 和 setter 的代码，我会认为它是正确的。这是在语言级别没有属性的一个主要缺点 - 您有很多生成的代码已签入源代码管理并且应该进行测试，因为它在覆盖率报告中尖叫。
On the other hand, even a simple getter might be incorrect, for instance due to C&P error:
另一方面，即使是简单的 getter 也可能不正确，例如由于 C&P 错误：
private String foo;
private String bar;
String getFoo() {return foo;}
String getBar() {return foor;}
My final thought: getters and setters are implicitly tested when appropriate logic using them is tested. Setter not covered in tests? - probably you are never setting this field and it might be final? Only setter but no getter called? - useless field?
我最后的想法是：当测试使用它们的适当逻辑时，隐式测试 getter 和 setter。测试中未涵盖 Setter？- 可能你从来没有设置这个领域，它可能是最终的？只调用了 setter 而没有调用 getter？- 无用的领域？
回答by CMR
You might need to/forced to unit test getters and setters for a couple of reasons:
1. Code coverage2. Automated regression testing
出于以下几个原因，您可能需要/被迫对 getter 和 setter 进行单元测试：
1. Code coverage2.Automated regression testing
In these cases you could use libraries that generate these junit test cases, or, write a single utility method using generics to set an object, get it back and compare if they are equal.
在这些情况下，您可以使用生成这些 junit 测试用例的库，或者使用泛型编写单个实用程序方法来设置对象，将其取回并比较它们是否相等。
回答by eav
This function doesn't change anything at this string... --> no complex setter
此函数不会更改此字符串的任何内容... --> 没有复杂的 setter
setTest(String test) {
this.test = test;
}
but if you have something like that, it would make sense to test it (because someone could have changed the token e.g.):
但是如果你有类似的东西，测试它是有意义的（因为有人可能已经改变了令牌，例如）：
String token=";";
setTestTwo(String testTwo) {
this.testTwo = testTwo + tokenString;
}
