Должны ли доменные объекты и простые JavaBean-компоненты тестироваться модульно?

Question

Должны ли модульно тестироваться простые JavaBeans, которые имеют только простые геттеры и сеттеры?

А как насчет Бинов с некоторой логикой в ​​методах получения и установки?

Answer 1

Вы не должны писать тесты, которые:

• Проверка языка или среды IDE (т. Е. Автоматически сгенерированных методов получения и установки)
• Не добавляйте ценности в свой тестовый комплект и убивайте свой энтузиазм по модульному тестированию

То же самое относится к объектам .NET, которые имеют только свойства (иногда называемые объектами «Info»).

В идеальном мире у вас будет 100% тестовое покрытие, но на практике этого не произойдет. Поэтому тратьте деньги клиента там, где это принесет наибольшую пользу, то есть написание тестов для классов со сложным состоянием и поведением.

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

Answer 2

Если не стоит тестировать, то не стоит писать.

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

Answer 3

Я думаю, что это один из тех вопросов, который каждый задает себе.

Но учтите это: внутренняя логика аксессоров сейчас очень проста, но она может измениться в будущем, и, что гораздо важнее, вы можете сменить ее на что угодно, если у вас есть тесты методы. Итак, вы получаете свободу и уверенность с помощью пары тестовых случаев. Звучит как хорошая сделка, да?

Answer 4

Другое эмпирическое правило (аналогичное тому, что говорили другие) - «проверяй все, что может сломаться». Для меня это исключает автоматически сгенерированные геттеры и сеттеры, но включает рукописные, содержащие некоторую логику.

Answer 5

Как вы можете безопасно рефакторинг непроверенного кода? Что произойдет, если ваш бобовый pojo изменится, если у вас нет тестов? Вы создаете модель Anemic Domain ?

Answer 6

Вы должны проверить вещи, которые имеют какое-то значение. Методы получения и установки обычно не содержат никакой логики и просто используются в Java из-за отсутствия свойств. Я думаю, что проверять их так же глупо, как проверять, что Java возвращает значение каждый раз, когда вы оцениваете «a.x».

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

Answer 7

Вам нужно только протестировать то, с чем вы хотите работать правильно.

(Извините, у кого я украл эту цитату)

Answer 8

Если он имеет внешний интерфейс и содержит код, который написал человек (в отличие от автоматической генерации в IDE или компиляторе), то он обязательно должен быть протестирован.

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

Answer 9

На мой взгляд, целью написания юнит-теста является тестирование бизнес-логики тестируемого юнита. Следовательно, если отсутствует бизнес-логика (например, когда получатель просто возвращает значение или его устанавливает установщик), то нет смысла писать тест. Если, однако, есть какая-то логика (получатель изменяет данные каким-либо образом перед их возвратом), тогда да, вам нужно пройти модульный тест. Как правило, я считаю, что не следует писать тесты для bean-компонентов, которые не содержат никакой бизнес-логики.

Answer 10

Как уже сказал Максим: наличие тестов не добавит дополнительную функциональность вашему приложению, но позволит вам вносить изменения с большей уверенностью. Чтобы определить, какие классы / методы должны быть проверены модулем, я всегда задаю себе два вопроса:

• импортируется ли этот фрагмент кода относительно общей функциональности?
• изменится ли этот фрагмент кода за время существования этого приложения?

Если на оба вопроса дан ответ «да», необходим юнит-тест.