Search code examples
javaunit-testingjunitdbunit

how to verify object properties while write unit test


    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)


Solution

  • 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.