как проверить свойства объекта при записи модульного теста

Question

    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)

Answer 1

Должен ли я проверять каждое свойство этого объекта?

Да, вам следует.В противном случае вы бы частично проверили состояние объекта, что может привести к неопределенным данным для непроверенных свойств.

Каков наилучший способ проверки таких операций доступа к данным (в настоящее время я использую dbunit)

Утверждение равенства фактического содержимого набора данных / таблицы и предварительно определенного содержимого набора данных / таблицы.Это описано в руководстве по DbUnit .Это имело бы смысл для операций с мутацией, включающих INSERT, DELETE или UPDATE.

Для операций SELECT вы можете утверждать значения в реальном и ожидаемом объектах или читатьСвойства объекта в карту, и сравнить его с ожидаемой картой.Если вы реализовали equals() (и hashcode()) для учета всех свойств объекта, assertEquals() должно быть достаточно для проверки объектов на равенство.Если вы не реализовали equals() для рассмотрения всех свойств объекта на равенство, вы можете вместо этого использовать метод assertThat() с пользовательским сопоставителем, чтобы проверить, равны ли свойства объекта.

Дополнительно, еслиу вас есть несколько таких тестов, которые имеют известный набор входных данных для операции DAO и ожидаемое содержимое набора данных / таблицы после операции DAO, вы можете рассмотреть параметризацию тестов , так что последовательность тестов будет определена только один раз,но тест выполняется несколько раз с разными входами, и система получает разные ожидаемые результаты.

Answer 2

assertEquals ожидаемый объект и извлеченный объект должны работать, я полагаю. (Я думаю, что для этого необходимо переопределить equals метод соответствующим образом.)

Answer 3

Если вы чувствуете, что есть риск забыть загрузить один из атрибутов или заменить два из этих атрибутов, то обязательно протестируйте его.

Если вы думаете, что это никогда не произойдет, не проверяйте это и ждите, пока не произойдет ошибка.Если это произойдет, введите юнит-тест, который не проходит из-за этой ошибки, исправьте ошибку и убедитесь, что юнит-тест больше не терпит неудачу.

Короче: абсолютного правила не существует, и онорешать вам

Answer 4

Может быть полезно протестировать операцию выбора из базы данных, особенно если в нее вовлечены некоторые обычные или сложные запросы выбора.

Я считаю, что ваша главная задача - убедиться, что при изменении этого класса он выиграет 'не нарушайте свои модульные тесты, если отображение базы данных все еще в порядке.Вы можете реализовать очень общий механизм сравнения полей (например, пользовательский метод равенства для всех полей) или использовать какой-то существующий - например, EqualsBuilder.reflectionEquals от Apache Commons.