Моя компания хочет применить TDD в наших проектах, и мы начали изучать TDD 5 месяцев назад. Мы начинаем с написания единицы измерения на экзамены (вы можете видеть в http://uet.vnu.edu.vn/~chauttm/TDD/). Затем мы следуем этой книге «grow_object-oriented_software_guided_by_tests», чтобы выполнить пилотный проект. Но у нас есть проблема с испытательной установкой (архитектура для тестирования сквозной системы) https://docs.google.com/file/d/0B23s8xkJtB5ZNHBJbEZ3YTdMTWc/edit. У нас есть 3 команды, команда развивает сервисную сторону, команда разрабатывает клиент Android, а команда разрабатывает клиент iOS. Следуя тестовой установке, клиентские команды будут записывать приемочные тесты и вставлять непосредственно данные в базу данных. Команда обслуживания создаст файл sql, тогда команды клиентов будут использовать этот файл для вставки в базу данных. Клиентские команды не знают обо всей базе данных (наша система имеет более 200 таблиц), и иногда им приходится тратить много времени на отладку, поскольку они не знают ошибок службы. Можете ли вы дать мне еще одну испытательную установку или предложить мне способы сделать наши проекты (в TDD) более эффективными?Испытательная установка в TDD (разработка, основанная на испытаниях)
ответ
Команды-клиенты должны обладать макетным уровнем обслуживания, с которым они пишут автоматические тесты. Это будет иметь преимущество быстрого запуска и не требует координации с сервисной командой. Большинство приемочных испытаний для клиентского приложения должны быть написаны таким образом. Если вы пишете приложение, использующее API календаря Google, вы не будете пытаться воссоздать весь API календаря, вы просто издеваетесь над API-интерфейсом календаря так, как вы ожидаете его работы.
Для тестов интеграции между командами вы можете иметь версию производственной службы на отдельном сервере с копией производственной базы данных с некоторыми тестовыми данными. Для тестирования настройте клиентов на использование конечной точки тестирования вместо производства.
, пожалуйста, ознакомьтесь с нашей тестовой установкой https://docs.google.com/file/d/0B23s8xkJtB5ZNHBJbEZ3YTdMTWc/edit. Как вы можете видеть, клиентские команды будут писать тесты проверки, и они должны напрямую вставлять sql-файл в базу данных. Таким образом, использование mock-сервиса может не применяться –
Зачем им вставлять SQL напрямую? Я бы указал стрелку на уровне сервиса, а не на уровень базы данных. –
Потому что мы должны вставлять данные в сервис для тестирования. –
Это звучит как интересный вопрос. Не могли бы вы объяснить немного более подробно, где проблема? Я не совсем понимаю, пишете ли вы о клиентских или серверных базах данных. – tmh
Моя компания аутсорсинг для компании в США. Их система развилась 20 лет назад. Это большая система. И теперь они хотят применить TDD для разработки других функций. –