Существует ли платформа модульного теста Java, которая автотестирует методов get и методы set? [закрытый]

Я буду одобрять дизайн OO по покрытию кода и видеть, не могу ли я переместить те поля в класс, которому нужны они. Таким образом, я попытался бы видеть, могут ли те методы get и методы set быть удалены, как предложено прежде. методы get и методы set повреждающаяся инкапсуляция .

В большей части метода set случаев и метода get делают больше как только установка и получение внутреннего поля. Объект должен проверить внутренние правила, что он содержит только допустимые значения. Например

• действительно ли нулевые значения возможны?
• действительно ли пустые строки возможны?
• или отрицательные величины?
• или нулевое значение?
• или значения из списка допустимы?
• или там максимальное значение?
• или там максимальная точность на значениях BigDecimal?

модульный тест должен проверить, исправляет ли поведение если там недопустимые значения. Это не может быть автоматизировано.

, Если у Вас нет логики на методе set и методе get тогда, он должен использоваться где угодно в Вашем приложении. Запишите тест, где Ваш объект является параметром для более сложного теста. Можно протестировать его тогда с различными значениями из списка.

Тест Ваша бизнес-логика а не метод get и метод set. Результат должен также покрытие метода get и метода set. Методы должны быть любым результатом в Вашей бизнес-логике также, если у Вас есть только публичная библиотека. Если у метода get и метода set нет покрытия кода, тогда удалил его.

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

я сомневаюсь, что автотестирование методов get и методов set приносит пользу Вашему качеству кода или Вашему покрытию: Любой эти методы используются от другого кода (и тестируются там, например, покрытых 100%), или не использовал вообще (и мог быть удален). В конце Вы оставите внутри методов get и методы set, потому что они используются от теста, но больше нигде в приложении.

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

Я сделал что-то как этот. Простой класс Java, который берет объект и тестирует всех методов get и методы установщика. http://sourceforge.net/projects/getterandsetter/

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

Ответ на предыдущий комментарий в @me здесь из-за моей репутации:

Vlookward, не запись методов get/методов set не имеет никакого смысла вообще. Единственные опции для установки частных полей состоят в том, чтобы иметь явные методы set, чтобы установить их в Вашем конструкторе или установить косвенно с помощью других методов (функционально задерживающий метод set к другому месту). Почему бы не использовать методы set?

ну, иногда, нет никакой потребности к полю быть частной (Извините, если мой английский язык не очень хорош). Часто, мы пишем наше программное обеспечение, поскольку это была библиотека, и мы инкапсулируем наши поля (наши поля бизнес-логики) с ненужными методами get/методами set.

Другие времена, что методы на самом деле необходимы. Затем существует две возможности:
1. Существует бизнес-логика в них. Тогда они должны быть протестированы, но они не настоящие методы get/методы set. Я всегда пишу что логика в других классах. И тестовый тест, что другие классы, не POJO.
2. Нет. Затем не пишите им вручную, если Вы можете. Например, реализация для следующего интерфейса может быть полностью автоматически сгенерирована (и также во времени выполнения!):

interface NamedAndObservable {
  String getName();
  void setName(String name);
  void addPropertyChangeListener(PropertyChangeListener listener);
  void addPropertyChangeListener(String propertyName,
                                 PropertyChangeListener listener);
}

Так тестируют только, что записано вручную. Неважно, если это - метод get/метод set.