Тесты JUnit - что мне тестировать? - PullRequest
0 голосов
/ 21 декабря 2009

Если у меня есть базовый метод доступа, который возвращает ArrayList

Что именно я бы проверил на это? Я очень неопытен, когда дело доходит до тестирования.

Ответы [ 6 ]

2 голосов
/ 21 декабря 2009

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

1 голос
/ 21 декабря 2009

Обычно написание явных тестов Junit для аксессоров обычно немного излишне (что вы тестируете? Return foo;). Использование инструмента покрытия кода , такого как clover , может помочь вам сначала направить свои усилия на тестирование на наиболее сложный код.

1 голос
/ 21 декабря 2009

Интересный вопрос для вас:

Сколько стоит юнит-тест "test"

Как использовать Junit и Hibernate с пользой

Что не должно быть проверено модулем

Редактировать:

Добавлены некоторые из моих любимых вопросов здесь, в Stackoverflow, относительно JUnit и модульного тестирования.

0 голосов
/ 21 декабря 2009

Зависит от ваших требований. Вы можете проверить:

  1. Если возвращаемое значение не равно нулю
  2. Если возвращенная коллекция не пуста
  3. Если возвращаемая коллекция является модифицируемой / неизменяемой
  4. Если возвращенная коллекция отсортирована
  5. Если возвращенная коллекция содержит все ожидаемые значения
  6. Если метод доступа не выдает исключение времени выполнения

Но, как я уже сказал, это зависит от требований, это зависит от типа сбора, который вы ожидаете, когда вызываете метод доступа. Возможно, вы разрешите установить список на null, но создадите пустой список. Тест может убедиться, что вы действительно получите пустой список, когда установите для него значение null.

Надеюсь, это поможет вам понять!

0 голосов
/ 21 декабря 2009

В общем модульные тесты должны проверять, что ваш метод делает то, что он должен делать.

Если ваш метод возвращает arraylist, ваш основной тест должен утверждать, что arraylist действительно возвращается, когда он вызывается.

Следующий уровень детализации в тесте - проверка правильности построения массива массивов. Правильно ли указаны ожидаемые значения? Если это должен быть пустой список, так ли это?

Теперь у вас есть случай «солнечного дня» (т. Е. Метод работает в нормальных условиях), при необходимости вы должны добавить некоторые отрицательные (или «дождливый день») условия. Если метод принимает длину для массива, что делать, если вы передаете отрицательное число или int.Max и т. Д.

Как указано в другом ответе, для простого средства доступа это, вероятно, излишне, но принципы применимы к любым модульным тестам, которые вам нужно написать.

0 голосов
/ 21 декабря 2009

Всегда помните, что тестовый код также является кодом, и на каждую 1000 строк кода вы выводите не менее 4 ошибок. Поэтому проверяйте, что не работает, и не пишите тесты для чего-то, что не может быть повреждено (например, код, сгенерированный вашей IDE). Если он сломается, напишите тест:)

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