Испытательная разработка - когда/что тестировать?

Question

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

1) Получите некоторые форматированные данные JSON на конечной точке REST и сохраните их в базе данных. Скажем, данные были несколько автомобилей записи -

{ "автомобили": [{ "сделать": "брод", "цвет": "синий", "год": "2010", "for_sale": правда }, { "сделать": "БМВ", "цвет": "черный", "год": "2011", "for_sale": ложные } ]}

Чтобы данные поступали в RES T, и мне нужно сохранить его в базе данных. Нужен ли мне тест для этой задачи, и если да, то на что это должно выглядеть?

2) Извлеките некоторые записи из базы данных и отобразите их на странице просмотра/веб-страницы (например, используя некоторую систему шаблонов). Скажет запись запись автомобиля выше и они должны быть представлены следующим образом: -

<ul id="cars"> 
    <li id="car-1"> 
     <div><span>Make:</span><span>Ford</span> 
     </div> 
     <div><span>Color:</span><span>blue</span> 
     </div> 
     <div><span>Year:</span><span>2010</span> 
     </div> 
     <div><span>For sale:</span><span>Yes</span> 
     </div> 
    </li> 
    <li id="car-2"> 
     <div><span>Make:</span><span>BMW</span> 
     </div> 
     <div><span>Color:</span><span>black</span> 
     </div> 
     <div><span>Year:</span><span>2011</span> 
     </div> 
     <div><span>For sale:</span><span>No</span> 
     </div> 
    </li> 
</ul> 

Так что мне нужна тест для этой задачи, и если да, то это должно выглядеть?

Answer 1

Какой язык, платформы и т. Д. Вы используете? Возможно, мы найдем для вас несколько примеров.

TDD сначала сложный, и задача, подобная этой (с базой данных и веб-частями), требует тестирования на нескольких уровнях.

Сначала разделите задачу на отдельные обязанности (которые, вероятно, сопоставляются с классами), которые могут быть подвергнуты блочной проверке. Например, класс, который принимает вход JSON и увлажняет объект со свойствами на нем, TDD этого класса. Уровни базы данных трудно тестировать, мы обычно используем шаблон репозитория, который затем мы издеваемся при тестировании других классов.

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

HTML/web тестирование также лучше всего выполняется на высоком уровне с использованием таких инструментов, как selenium webdriver, что позволяет вам написать тестовый код, который запускает настоящий браузер, взаимодействует с вашей страницей и утверждает, что контент/поведение как ожидается.

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

---

Редактировать: Java и Play framework. ОК, я не знаю рамки для игр специально, но из-за быстрого взгляда, вероятно, JSON-синтаксический анализ для вас, если вы настроите его правильно, что уменьшает функцию синтаксического анализа json до шаблона. Здесь нет большой ценности в TDD, но вы можете, если хотите. Точно так же есть стиль db-слоя с активной записью? Таким образом, в тестовом коде, предоставленном вашей библиотекой, нет большой ценности (и dbs являются жесткими/невозможными/бессмысленными) для модульного теста).

---

Edit: Edit - это оказывается противный, По-видимому Play uses static controller methods which makes it hard to unit test (because you can't inject dependencies - which makes mocking difficult). Я боюсь, что не выполняя много часов исследований, я не могу помочь в деталях, но интеграционные тесты - это, вероятно, путь сюда, который тестирует несколько ваших блоков кода вместе, включая БД.

Так что в итоге:

• Не переживайте TDD на шаблонный. Сохраняйте изолированную оболочку и предмет (то есть контроллеры ТОЛЬКО делают веб-материал, а затем передают другим классам. Репозитории сохраняют и извлекают объекты, а не правила/решения/манипуляции.
• Когда вы начинаете добавлять больше бизнес-логики в кишки вашего приложения - держите его изолированным в бизнес-классах (т. е. вдали от веб-сайта или db-шаблона), который вы можете легко тестировать. Определенно TDD этот материал.
• Попробуйте выполнить интеграционные тесты в своем приложении, чтобы протестировать БД. ваше приложение, используйте приложение, чтобы сохранить что-то, получить его, а затем утверждают, что это правильно.
• использовать что-то вроде Selenium для проверки веб-страниц.

* удалить в соответствии с вашими убеждениями в отношении тестирования.