Когда не / писать тесты до реализации?

Question

Я не уверен, как работает «сначала тесты», и мне хотелось бы услышать аргументы о том, когда и почему следует использовать этот подход.

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

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

Answer 1

Главное правило: сначала делайте самые рискованные вещи.

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

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

Однако во многих проектах это не так, и применение TDD в этих случаях является плохим выбором.

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

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

Этот список можно продолжить.

Выполнение рискованных предметов сначала имеет много преимуществ:

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

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

• Деловая сторона вашей организации будет ценить проект выше, когда у него низкий риск неудачи; меньше шансов, что он будет отменен без необходимости раньше.

Answer 2

"Я слышал, что часто рекомендуется писать тесты и макетировать вещи перед написанием одной строки реализации ... В конце концов я возвращаюсь и пишу модульные тесты ... Это отличается от того, что вы" должны делать " "?"

Поскольку вы начали с ответа на свой вопрос, значит, вы на самом деле не задаете этот вопрос?

Есть много причин, почему люди отвечать на свои вопросы. Иногда это способ спорить.
Это позволяет людям сказать: «Я не спорю, я просто спрашиваю, почему это так неправильно ".

---

Цель - сначала проверить. Вот как это работает.

Допустим, я делаю прототип и пока не уверен, как все будет работать.

Я, однако, знаю одну вещь. Что он должен делать.

1. Запишите конкретный пример того, что он должен делать. Конкретные, конкретные входы и выходы.

2. Это тестовый пример. Я сделал это первым. Могу ли я оформить это как юнит-тест? Возможно нет. Однако я начал с приемочного теста.

Теперь я могу разбить проблему на части.

1. Так что я просто начинаю находить примеры каждого шага, который мне нужен.

2. Для каждого примера того, что мне нужно, я записываю, что входит и что выходит из шага.

3. Это тестовые случаи. Я сделал их первым. Во многих случаях я могу оформить их как модульные тесты.

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

Я сделал тестирование, затем кодирование. Я не делал ВСЕ тестирования до ЛЮБОГО кодирования. Сначала я проводил тестирование, но не сумасшедшим способом «все тесты без кода». Я сделал это в пошаговом тесте - немного кода - немного. Но сначала все было проверено.

Answer 3

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

Так что да, ваш подход верен, если вы проводите тестирование после прототипов

Answer 4

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

Затем, когда код выбрасывается, у вас все еще есть тесты.

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

Answer 5

Я думаю, что ваш подход не тестировать шип / прототип - это просто замечательно. Но две идеи:

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

2. если у вас больше практических тестов с модульными тестами, вы можете быстрее создать свой прототип в тесте, чем создать консольное приложение. Я не имею в виду создание тестов и отдельного класса с идеей, я имею в виду исследовать код прямо в методе тестирования. Я делал это несколько раз, и я был очень счастлив с этим. Когда я изучаю новый API или даже новый язык, тест дает мне самый быстрый цикл обратной связи для попытки эксперимента. Затем, когда код заработает, я могу извлечь его в отдельный метод / класс, чтобы он стал частью реальной системы.

Answer 6

Не существует единственного «правильного способа сделать это». Тем не менее, я думаю, что разработка через тестирование (TDD) поможет в вашем случае. Я считаю, что написание тестов сначала помогает сформировать API и делает код чище. Когда вы сначала пишете тесты, вы сначала думаете о том, как будет вызываться код (интерфейс или «что это должно делать»), прежде чем думать о реализации («как я должен это делать»).

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

Assert.AreEqual (Customer1, crm.GetMostValuableCustomer (), «самый ценный клиент не такой, как ожидалось»);

Затем вы можете добавить что-то вроде:

Assert.AreEqual (новый клиент [] {клиент1, клиент2, клиент3}, crm.GetCustomerByValue (), «GetCustomersByValue () не так, как ожидалось»);

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

Answer 7

Я считаю, что сначала написание тестов не работает так хорошо, когда я все еще строю "историю" своего кода. Трудно писать тесты, когда я не уверен, как выглядят интерфейсы. Я мог бы написать код заглушки, чтобы конкретизировать классы и интерфейсы, не думая о тестах. Но я стараюсь пройти тесты как можно быстрее. Я считаю, что это помогает, если я делаю заметки о том, что я буду тестировать, когда создаю дизайн, а затем, когда мой дизайн становится более твердым, я возвращаюсь к своим заметкам и делаю эти тесты первыми. Обычно это означает, что код реализации и модульного теста срастается, ни один перед другим.