用于 getter 和 setter 的 JUnit
正如我正在阅读的一本书中强烈推荐的那样，我开始为我正在创建的每个类编写测试。我不太确定覆盖 setter 和 getter 的好习惯是什么。如果是，我不知道如何验证，因为要验证 setter 方法，您需要调用该变量的 getter 方法，反之亦然。所以你永远不会知道真正的问题出在哪里。 我去的地方只是针对 setter 和 getter 的类似测试。
As it was highly recommended in one of the books I'm reading I've started to write tests for each of the class I'm creating. I'm not really sure what is a good practice to cover setters and getters or not. If yes I'm not sure how because to verify the setter method you need to call the getter for this variable and vice versa. So you will never know where the actual problem is.
Where I went is just similar tests for setters and getters.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
如果您实践 TDD（测试驱动设计），setter 和 getter 只会在您需要时才会出现 - 您不会只是“以防万一”自动预先创建它们。在这种情况下，对访问器的需求通常会在对不太基本的方法进行已经失败的测试过程中出现。这意味着您的访问器将被测试，不是通过特定的测试，而是在测试更广泛的方法的过程中。这样更好； “以防万一”创建访问器是愚蠢的，为如此琐碎的方法编写测试也是愚蠢的。但很高兴对它们进行测试。
If you practice TDD (Test-Driven Design), the setters and getters will emerge only as you have a need for them - you don't just automatically create them up front "just in case". In this case, the need for the accessor will typically emerge in the course of an already-failing test for a less-rudimentary method. This means that your accessor will be tested, not by a specific test for it, but in the course of testing the broader method. That's better; it's silly to create accessors "just in case," and silly to write tests for methods that are as trivial as that. But it's nice to have them test-covered.
如果你关心覆盖率指标，setter 和 getter 可能会杀了你。
不管怎样，你绝对应该测试它们，特别是当它们做的不仅仅是设置或获取时。
另外，可以在一次测试中测试设置/获取。如果道具是私有的，那么你必须这样做，除非集合有副作用。或者您可以在测试其他方法时隐式测试它们。例如，如果您正在测试 DAO，则可以在编写 testSave 方法时使用 setter 和 getter...
为了让生活更轻松，您可以编写基于反射的测试实用程序来测试 setter 和 getter。或者只是编写简单的测试，虽然很无聊，但并不难或耗时...
这里有很多选择...
If you care about coverage metrics, setters and getters can kill you.
Regardless of that, you should definitely test them, especially if they do more than set or get.
Also, its OK to test set/get in one test. If the props are private, then you have to do it that way, unless there are side effects of a set. Or you can implicitly test them when testing other methods. For example, if you are testing a DAO, you can use the setters and getters when you write you testSave method...
To make life easier, you might be able to write a reflection based test utility to test setters and getters. Or just write simple tests, its not hard or time consuming, although it is boring...
There are a lot of options here...
如果您的 getter 和 setter 只是获取和设置支持变量，那么为它们编写单元测试不会提供太多价值，因为您本质上是在测试语言和编译器是否正在执行它们应该执行的操作。
相反，应专注于测试行为是否按预期工作。如果设置属性 A，这意味着属性 B 现在应该具有不同的值，这可能值得进行单元测试。
If your getters and setters are simply getting and setting a backing variable, then writing unit tests for them does not provide much value as you are essentially testing that the language and compiler are doing what they are supposed to.
Focus instead on testing that behavior works as expected. If you set property A, and that means property B should now have a different value, that might be worth a unit test.
测试驱动开发的哲学是“测试一切可能破坏的东西”。
Getter 和 Setter 对于代码来说很简单，通常由 IDE 为您生成。希望您的 IDE 开发人员已经测试了该代码，这样您就不必这样做。我会费心测试吸气剂的唯一情况是，如果他们做的不仅仅是设置/获取。
为您的业务逻辑编写测试，而不是为了编写测试而测试。
The philosophy of Test Driven Development says "test everything that can possibly break".
Getters and setter are trivial to code and are often generated for you by your IDE. Hopefully the developers of your IDE have already tested that code so you won't have to. The only case i would bother testing getters is if they do more than just set/get.
Write test for your business logic, not tests for the sake of writing tests.
编写单元测试的一般准则是您的测试类是否包含逻辑。
即使您有委托逻辑（业务层调用 dao 层），我也建议为其编写测试。
至于值对象（或 POJO），您可以避免单元测试。
但是，如果您确实希望测试这些对象 - 请使用反射。
您可以使用反射设置一个字段，然后查看 getter 返回什么。您可以使用设置器设置字段并再次使用反射检查值。
General guideline for writing unit test is if your tested class contains logic.
Even if you have a delegation logic (business layer calls dao layer), I would recommend writing tests for it.
As for value objects (or POJOs to that matter), you can avoid unit testing.
BUT, if you do wish to test those object - use reflection.
You can set a field with reflection and see what the getter returns. You can set the field with a setter and check the value using reflection again.