如何在编写单元测试时验证对象属性

发布于 2024-11-29 15:25:12 字数 1428 浏览 0 评论 0原文

    private Long itemId;

    private String longName;

    private String shortName;

    private String itemUrl;

    private Integer itemCount;

    private Long parentCategory;

    private Long childCategory;

    private Integer shopType;

    private Integer payPostage;

    private Long originalPrice;

    private String picUrl;

    private Long activityPrice;

    private String city;

    private String itemDesc;

    private Integer itemStatus;

    private String itemGuarantee;

    private Double discount;

    private String checkComment;

    private Long platformId;

    private Long sellerId;

    private String sellerNick;

    private Integer sellerCredit;

    private Long categoryId;

    private Long operatorId;

    private String operatorNick;

    private String sellerEmail;

    private String sellerPhone;

    private String sellerAddress;

    private String sellerShopUrl;

    private String sellerRealName;

    private String picUrlFromIC;

    private Integer itemType;

    private Integer tgType;

    private String attributes;

    private Integer isAuth = 0;

    private String[] itemCities;

    private Integer isBlack = 0;

    private double lowestPirce;

    private transient int pollNum;

    private Integer limitNum;

这就是我拥有的物体。
当我测试选择操作时(从 mysql 选择对象)。
我应该验证该对象的每个属性吗?
测试此类数据访问操作的最佳方法是什么(我当前正在使用 dbunit)

    private Long itemId;

    private String longName;

    private String shortName;

    private String itemUrl;

    private Integer itemCount;

    private Long parentCategory;

    private Long childCategory;

    private Integer shopType;

    private Integer payPostage;

    private Long originalPrice;

    private String picUrl;

    private Long activityPrice;

    private String city;

    private String itemDesc;

    private Integer itemStatus;

    private String itemGuarantee;

    private Double discount;

    private String checkComment;

    private Long platformId;

    private Long sellerId;

    private String sellerNick;

    private Integer sellerCredit;

    private Long categoryId;

    private Long operatorId;

    private String operatorNick;

    private String sellerEmail;

    private String sellerPhone;

    private String sellerAddress;

    private String sellerShopUrl;

    private String sellerRealName;

    private String picUrlFromIC;

    private Integer itemType;

    private Integer tgType;

    private String attributes;

    private Integer isAuth = 0;

    private String[] itemCities;

    private Integer isBlack = 0;

    private double lowestPirce;

    private transient int pollNum;

    private Integer limitNum;

That is the object i have.
When i test a select operation(select the object from mysql).

should i verify each property of this object??

what is the best way to test such data access operations(I am using dbunit currently)

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

海风掠过北极光 2024-12-06 15:25:12

我应该验证该对象的每个属性吗?

是的,你应该。否则,您将部分验证对象的状态,可能会导致未验证的属性出现未指定的数据。

测试此类数据访问操作的最佳方法是什么(我当前使用dbunit)

断言实际数据集/表内容与预先确定的数据集/表内容相等。 DbUnit 操作指南对此进行了介绍。这对于涉及 INSERTDELETEUPDATE 的变异操作是有意义的。

对于 SELECT 操作,您可以断言实际对象和预期对象中的值,或者将对象的属性读取到 Map 中,并将其与预期 Map 进行比较。如果您已实现 equals()(和 hashcode())来考虑所有对象属性,则 assertEquals() 应该足以验证对象为了平等。如果您尚未实现 equals() 来考虑对象的所有属性是否相等,则可以使用 assertThat() 方法,并使用自定义匹配器来验证对象的所有属性是否相等。对象属性是相等的。

此外,如果您有多个此类测试,这些测试具有 DAO 操作的一组已知输入以及 DAO 操作后的预期数据集/表内容,您可以考虑 参数化测试,以便测试序列仅定义一次,但测试使用不同的输入执行多次,并对系统进行断言具有不同的预期输出。

Should i verify each property of this object?

Yes, you should. Otherwise, you would partially verify the state of the object, potentially resulting in unspecified data for the the unverified properties.

What is the best way to test such data access operations(I am using dbunit currently)

Assert for equality of the actual dataset/table contents and the pre-determined dataset/table contents. This is covered in the how-to guide of DbUnit. This would make sense for mutating operations involving INSERT, DELETE or an UPDATE.

For SELECT operations, you can assert the values in the actual object and an expected object, or read the properties of the object into a Map, and compare it against the expected Map. If you've implemented equals() (and hashcode()) to consider all object properties, assertEquals() should be sufficient for verifying objects for equality. If you haven't implemented equals() to consider all the object's properties for equality, you can use the assertThat() method instead, with a custom matcher to verify if the object properties are equal.

Additionally, if you have multiple such tests that have a known set of inputs for an DAO operation and expected dataset/table contents after the DAO operation, you can consider parameterizing the tests, so that the test sequence is defined only once, but the test is executed multiple times with different inputs, and the system is asserted with different expected outputs.

挽袖吟 2024-12-06 15:25:12

我认为预期对象和检索到的对象上的 assertEquals 应该有效。 (我认为这需要您适当地重写 equals 方法)。

assertEquals on the expected object and retrieved object should work I suppose. (I think this requires you overriding equals method appropriately).

财迷小姐 2024-12-06 15:25:12

测试数据库中的选择操作可能很有用,特别是在涉及一些 orm 或复杂的选择查询时。

我相信您主要关心的是确保当您更改此类时,如果数据库映射仍然正常,它不会破坏您的单元测试。您可以实现非常通用的字段比较机制(例如所有字段上的自定义 equals 方法)或使用一些现有的比较机制 - 例如 EqualsBuilder.reflectionEquals 来自 Apache Commons。

It can be beneficial to test select operation from the database especially if there is some orm or complicated select queries involved.

I believe your main concern is to make sure that when you change this class it won't break your unit tests if database mapping is still fine. You could implement very generic field comparison mechanism (like a custom equals method on all fields) or use some existing one - like EqualsBuilder.reflectionEquals from Apache Commons.

巴黎盛开的樱花 2024-12-06 15:25:12

如果您觉得存在忘记加载其中一个属性或替换其中两个属性的风险,那么一定要测试它。

如果您认为它永远不会发生,请不要测试它,并等待错误发生。如果发生这种情况,请引入由于此错误而失败的单元测试,修复该错误,并验证单元测试不再失败。

简而言之:没有绝对的规则,由你决定

If you feel there is a risk of forgetting to load one of the attributes, or substituting two of these attributes, then definitely test it.

If you think it'll never happen, don't test it, and wait for a bug to happen. If it happens, introduce a unit-test which fails due to this bug, fix the bug, and verify that the unit-test doesn't fail anymore.

In short: there is no absolute rule, and it's up to you to decide

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文