TDD: что происходит перед первым модульным тестом?

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

Например, допустим, я хочу написать приложение, которое поможет нашей семье справляться с домашними заданиями. У меня есть несколько вопросов: как перейти от этой идеи к моему первому тесту? Сколько нужно определиться до того, как я начну, и сколько я выясню после того, как начну писать тесты? Когда я принимаю решение, например, хранить ли данные в текстовом файле или базе данных? Должны ли я пройти приемочные тесты перед началом работы? Должен ли я иметь разработанный интерфейс? Должен ли я иметь спецификацию? (Я понимаю, что, по крайней мере, некоторые из этих примеров вопросов, вероятно, находятся в «серой области»).

В дополнение к заглавному вопросу о получении первого модульного теста, не могли бы вы привести пример того, как может выглядеть первый модульный тест для проекта, такого как пример проекта?

Мне нравится начинать со списка функций, и для каждой функции писать пользовательские истории, а затем для каждой истории писать описания тестов.

Подумайте немного о дизайне, затем выберите описание теста и начните писать код: red-green-refactor.

Повторяйте, пока все тесты не пройдут.

Да, приемочные тесты должны рассматриваться как часть этого, приложенного к соответствующей истории.

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

Разработчики, которые не используют TDD, тоже должны подумать об этом - но они могут «просто погрузиться» и начать что-то писать, что угодно. Но «что-то, что угодно» не всегда на пути к реализации программы, которую, как вы думали, вы намереваетесь написать. Что? Ну, как бы выглядела ваша программа, если бы она работала? Какие тесты это пройдет?

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

Здорово. Если бы это приложение работало, что бы оно делало? Что ж, работа по дому может быть назначена человеку, верно?

Person fred = new Person("fred")
Chore mow = new Chore("mow the lawn");
mow.assignTo(fred);
assertEquals(fred, mow.whoIsAssigned());

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

Да, у TDD есть эта проблема. Вот почему я сейчас рекомендую Behavior Driven Development.

Начните вручную. Запишите что-то похожее на историю пользователя:

• Как пользователь
• Когда я выбираю Добавить в корзину, я хочу, чтобы продукт был добавлен прозрачно в фоновом режиме.
• Так что я могу продолжать покупки без перерыва

Теперь, какие функции поддерживают эту цель (часть «Так что»)?

• Когда товар добавлен в корзину
  • Корзина покупок для пользователя будет содержать новый товар
  • Общее количество товаров в корзине увеличится на один
  • Пользователь не должен быть перенаправлен
  • Опция проверки сейчас будет доступна
• Когда в корзине есть два товара и пользователь выбирает оформить заказ
  • Пользователь будет перенаправлен на страницу оформления заказа
  • Оба элемента будут видны

Это все, что вы можете и должны проверить вручную.

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

.Net имеет WatiN для автоматизации веб-страниц или, если вы хотите протестировать API, я бы порекомендовал дополнение Subspec к xUnit или MSpec (вы также можете сделать это с любой средой тестирования, только они упрощают называть ваши тесты таким образом, чтобы что поддерживает этот стиль мышления).

Ruby имеет огурец для тестирования автоматизации и rspec для тестирования API более низкого уровня

В Javascript есть жасмин и qUnit.

точка точка точка

Как мне перейти от этой идеи к моему первому тесту? Сколько нужно определиться до того, как я начну, и сколько я выясню после того, как начну писать тесты?

Разбейте ваше приложение на кусочки. («Как пользователь, я хочу дважды щелкнуть по значку и запустить программу.» Или «Как пользователь, я хочу открыть свой браузер и перейти к программе.» Как угодно.)

Затем разбейте историю на несколько задач. (например, создайте проект в Eclipse, настройте хранилище кода). Когда вы приступите к задаче программирования, напишите свой первый тест.

Когда я принимаю решение, например, хранить ли данные в текстовом файле или базе данных?

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

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

Для получения дополнительной информации о TDD, я бы порекомендовал Test Driven Development By Example by Kent Beck. У него также есть скринкаст TDD, который следует за разработкой нетривиальной библиотеки в чистом стиле TDD с объяснениями Кента на каждом этапе процесса. Я думаю, что это отличный пример TDD на практике, даже если он (по необходимости) сделан в искусственной среде.

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

Промыть, повторить и т. Д.

Для меня важно думать о том, как вы бы это проверили, и это может повлиять на ваш дизайн.