Понимание разницы между «первым тестом» и «управляемым тестом»

Question

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

Вот что я думаю Я знаю:

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

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

Мои вопросы:

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

Answer 1

Ключевым аспектом разработки через тестирование является то, что вы не реализуете функциональность, которая не требуется для прохождения теста.Test-first просто означает написание теста до того, как вы реализуете функциональность.Это главным образом сделано, чтобы гарантировать, что тест фактически потерпит неудачу, если функциональность не присутствует.Разработка, основанная на тестировании, предполагает подход, основанный на тестировании, но не наоборот.

Answer 2

Я думаю, что вы хорошо поняли и четко сформулировали различие между тестированием вначале и тестированием, и, как указывает Бьорн, вся разработка, управляемая тестами, обязательно должна выполняться сначала.На ваш вопрос о том, как перейти от тестового мышления к тестовому мышлению, я бы предложил несколько раз выполнить относительно простое упражнение (скажем, реализацию Range или Rectangle), пытаясь каждый раз достигать другой реализации.В первый раз вы получите то, о чем думаете прямо сейчас - и это, как вы указываете, не обусловлено тестами.В следующий раз вы не сможете использовать то, о чем думаете;вам придется протянуть руку, чтобы придумать что-то другое, и некоторые из этих достижений произойдут в случае провала теста.Возможно, в третий раз вы начнете отказываться от своих предвзятых решений и просто будете делать то, что тест заставляет вас делать, - и вы на пути к тестовому мышлению.

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

Answer 3

Разница заключается в обнаружении ролей и интерфейсов.

• Если вы пишете свои тесты до того, как напишите код, вы получите значок Test-First.
• Если выTest-First, и вы слушаете ваши тесты, чтобы узнать, какие типы / роли / интерфейсы необходимы, и «развивать» свой дизайн с помощью JIT-рефакторинга, а затем вы получаете значок Test-Driven.

С test-Во-первых, вы, скорее всего, перейдете к дизайну (который может / не может быть самым простым / оптимальным выбором; в зависимости от ваших навыков), прежде чем писать тесты.Test-first также легко подает тесты на плохой существующий дизайн, однако прогресс будет медленным.Скорее всего, у вас будет сложный для тестирования код и медленные для записи тесты.

ИМХО Управляемое тестированием помогает мне написать более простые проекты, которые легко тестировать .

Как войти в образ мыслей?Это та часть, где вам нужна самодисциплина и практика.Да, трудно удержаться от гонок к решениям.+1 к Карлу за указание сделать несколько код-кат в исследовательском режиме, сделать другой выбор и посмотреть, чем он закончится.С несколькими под твоим поясом становится легче ... TDD фактически заставляет тебя "сосредотачиваться" на одной вещи за раз.

Answer 4

Написание набора тестов перед реализацией позволяет вам создавать модульные тесты для открытых методов.Итак, реальная реализация происходящего скрыта от теста.Вы кодируете для абстрактной, а не реализации, которая является хорошей вещью (TM).Вы берете в абстрактных терминах и понятиях - тесты сформируют, какими будут ваши публичные методы.Итак, тестирование означает, что ваши тесты будут управлять API.Обратное - это то, что вы называете test-first.