При каких условиях я должен тестировать методы get () и set ()? - PullRequest
4 голосов
/ 27 мая 2010

Я не могу подтвердить, стоит ли делать эти тесты. Кажется, метод set и get очень прост, например:

setA(String A) {
    this.A = A;
} 

getA(){
    return A;
}

Любые идеи будут оценены!

Спасибо, Джозеф

Ответы [ 9 ]

8 голосов
/ 27 мая 2010

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

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

public void setA(Object a) {
  this.a = a;
}
public Object getA() {
  return a;
}

public void setB(Object a) {
  this.a = a;
}
public Object getB() {
  return a;
}

Модульные тесты, которые фокусируются на одной паре сеттер / геттер одновременно, не выявят проблему.

Современные IDE будут генерировать геттеры и сеттеры по запросу, поэтому эта ошибка маловероятна, но не все используют современные IDE. (Пользователь vi создал вышеуказанную ошибку.) И если эти методы находятся в простом объекте-держателе данных, проблема может проявиться лишь немного дальше от причины.

По этой причине, если я тестирую геттеры и сеттеры вообще (а я часто этого не делаю), это из одного метода тестирования, который сначала вызывает все сеттеры с различными значениями, а затем проверяет все геттеры.

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

4 голосов
/ 27 мая 2010

Общее правило: не так много смысла в написании тестов для геттеров и сеттеров. Только если у них есть какая-то дополнительная логика, т.е. не чистые методы доступа, вы должны написать тесты.

2 голосов
/ 27 мая 2010

Единственный раз, когда я пишу тесты специально для методов set () и get (), это если внутри них есть какая-то логика. Например. ограничить целое число от 1 до 8


public void SetA(int a)
{
  if(a > 8 || a < 1)
  {
    throw new IndexOutOfBoundsException();
  }

  this.a = a;
}

Несмотря на то, что приведенный выше код является очень простым примером, когда вы выполняете логику такого типа, может быть хорошей идеей запустить тест на них. Главным образом для случаев, когда ваши бизнес-правила меняются, и вы должны ограничить их между 9 и 1:)

1 голос
/ 31 мая 2010

Умный человек однажды сказал: «Испытай, пока страх не превратится в скуку».Если вы больше не боитесь, что ваш супер-простой код сломается, не пишите тесты, если вам не скучно писать эти тесты.И не пишите тесты просто для «улучшения ваших показателей», это просто игровая система.Напишите тесты, чтобы убедиться, что ваш код работает, улучшить надежность и создать уверенность в том, что вы можете свободно проводить рефакторинг.

1 голос
/ 27 мая 2010

Да, в вашем случае они тривиальны - но с другой стороны - два простых теста, которые полностью учитывают показатели качества; -)

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

Может быть, однажды кто-то решит изменить тип поля или добавить какой-либо код преобразования единиц в установщик / получатель - тест покажет, работает ли код или покажет, что требуется дополнительная работа. *

1 голос
/ 27 мая 2010

Сделайте анализ затрат / выгод

Что бы получить

  • зная, что приватная переменная действительно прочитана / записана

Сколько это будет стоить

  • время, затраченное на написание контрольного примера

  • время, потраченное каждый раз при выполнении вашего тестового набора


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

0 голосов
/ 27 мая 2010

Предполагается, что юнит-тесты - это документация о том, как должна работать система. Хотя люди часто пропускают юнит-тесты для свойств, потому что функциональность тривиальна, если тесты - это документация и особенно если кто-то другой собирается сделать реализацию, то тесты для свойств должны быть написаны. Тем не менее, когда я пишу тесты и выполняю реализацию, я обычно пропускаю написание тестов для свойств, если они не выполняют нечто большее, чем простое получение / установка, или если у меня есть свободное время, что является редкостью.

0 голосов
/ 27 мая 2010

Написание контрольных примеров для методов, которые не могут потерпеть неудачу, кажется мне непропорциональным. Только если значение A инициализируется конфигурацией или чем-то, что может дать сбой это стоит проверить.

EDIT: Другим примером, когда тестирование имеет смысл, может быть флаг 'overdrawn', если баланс счетов становится отрицательным, и вы хотите проверить, правильно ли был установлен флаг после вызова методаdraw ().

0 голосов
/ 27 мая 2010

Они все одинаковые, я говорю, как пустые интерфейсы или бизнес-классы. Предварительная обработка должна разрешить все необходимое, или они являются другими видами (делатели, которые оба должны возвращать, как ответ и принимать 2 переменные), независимо от языка (даже при выходе из POSIX, который теперь пуст, следует использовать аргументы, поскольку знание пути очень важно)

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...