Тестовая разработка не работает для моего класса

Question

У меня есть этот класс, который я хотел построить с использованием TDD, но мне не удалось. Это довольно простой класс с именем SubMissions, и все, что он делает, это получает некоторые данные из базы данных SQL.

Так что у него есть такие методы, как getSubMissionForPage(), getSubMissionFromId() и т. Д.

Я попытался построить его с помощью TDD. Мой первый тест содержал вызов getSubMissionPage(), единственная цель которого - вернуть данные. Так что провалить этот тест довольно сложно, так как он может вернуть любые данные, и я не смог придумать, как его провалить.

Я знаю, что провал теста - это первый шаг к пониманию того, что реализовать, но что вы делаете, когда на самом деле нет способа провалить тест?

Answer 1

Каждый раз, когда вы полагаетесь на внешний источник данных, ваш тест всегда может провалиться.Что если соединение с вашей БД сброшено?Что если таблицы не существует, из которой вы пытаетесь получить данные?Что если возвращаемые вами данные не соответствуют ожидаемым?

Тестирование классов, подключающихся к БД, немного сложнее, чем тестирование HelloWorld.java, поскольку вам нужен какой-то способ макетировать БД .Вы можете узнать больше о Mock Objects здесь .

Краткий ответ, ваши тесты / программное обеспечение могут ВСЕГДА терпеть неудачу.Если вы не думаете, что ваш тест может провалиться, вы недостаточно задумаетесь о проблемном пространстве.

Answer 2

Извлечение из базы данных не место для начала с TDD.

Вы могли бы преуспеть, чтобы посмотреть на некоторые примеры TDD в сети. Оценка Боба Мартина *1003* - это забавное место для начала.

Как говорится ...

Мой первый тест содержал вызов getSubMissionPage (),единственная цель которого - вернуть данные.Так что провалить этот тест довольно сложно, так как он может вернуть любые данные, и я не смог придумать, как его провалить.

Цель состоит не в том, чтобы вернуть данные, а в том, чтобы вернуть правильные данные.

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

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

Но лучше не начинать с базы данных.

Answer 3

Пусть метод выдает исключение RuntimeException, если вы хотите, чтобы тест не прошел. Eclipse заполнит заглушки метода подходящим UnsupportedOperationException для вас.

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

Не пытайтесь подключиться к базе данных, пока один или два дополнительных теста не заставят вас.

Answer 4

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

Например, вы можете использовать Dependency Injection для отправки интерфейса в хранилище доступа к данным (используя в вашем тестовом случае фальшивку или макет), который позволит вам изолировать ваши тесты доступа к данным от ваших логических тестов. то есть создайте SubmissionRepository, который обрабатывает доступ к данным, а ваш класс представлений обрабатывает бизнес-логику, переходя в ваш репозиторий для базовых операций crud и shaping.

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

Answer 5

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

Начиная с тестирования базы данных, вероятно, не лучший способ погрузиться в TDD. Начните с класса, который не имеет зависимостей. Представьте себе игру в шахматы, у вас могут быть такие классы, как:

• Доска
• Площадь
• Местоположение (ряд, столбец квадрата на доске)

Я бы начал с Location, так как он не имеет зависимостей, затем Square, поскольку он зависит только от Location, затем Board, поскольку он зависит только от Square.

Answer 6

ub getSubMissionPage ‘не должен просто возвращать какие-либо данные - он должен сделать конкретный запрос, а затем вернуть что-то на основе запроса.

Вам необходимо настроить «SubMissions», чтобы использовать фиктивный источник данных, а затем проверить, что класс выполняет запросы к нему и правильно отображает данные в объекты.

Answer 7

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

(1) и(2) были просто упражнения, которые должны помочь вам убедиться, что тест работает.

Теперь задайте себе вопрос: что может быть причиной провала теста?Я думаю, что в вашем случае список причин выглядит следующим образом: 1. нет связи с БД 2. неверная схема БД 3. несогласованные данные

Вот способы моделирования этих причин: 1. выключите вашу БД или изменитеcredentials / jdbc URL, который вы используете для подключения.2. удалить интересующую таблицу или изменить имя (имена) ее столбцов.3. немного сложно сделать данные непоследовательными.Обычно это происходит, когда ограничения БД не определены правильно.Иногда люди делают это, чтобы сделать схему более общей.Если это не ваш случай, просто забудьте о # 3.

Удачи с TDD!Я верю, что в будущем ваши сценарии тестирования станут более сложными.

Answer 8

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

Посмотрите этот FAQ по JUnit: http://junit.sourceforge.net/doc/faq/faq.htm#best_3