Испытательная разработка - Что такое тест?

Question

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

Answer 1

В целом тест может быть ...

• unit test который проверяет индивидуальный субкомпонент вашего программного обеспечения без каких-либо внешних зависимостей к другим классам
• integration test которые тесты, которые проверяют соединение между двумя отдельными системами , т.е. их способность интеграции
• acceptance test для проверки функциональности системы

... и некоторые другие, я, скорее всего, временно забытые сейчас.

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

Answer 2

Вот несколько хороших статей Unclebob

Three rules of TDD

TDD with Acceptance and Unit tests

Answer 3

Это полностью блок испытания.

Основная идея - сначала написать единичные тесты, а затем выполнить абсолютный минимальный объем работы, необходимый для прохождения тестов.

Затем напишите больше тестов, чтобы охватить больше требований и реализовать немного больше, чтобы пройти.

Это итеративный процесс с циклами тестовой записи, а затем написанием кода.

Answer 4

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

Answer 5

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

См. words of wisdom Дядя Боб.

Answer 6

Как я использую это, это тестирование единицы измерения. Предположим, я хочу метод, квадратные Интс я пишу этот метод:

int square(int x) { return null; } 

, а затем написать несколько тестов, таких как:

[Test] 
TestSquare() 
{ 
Assert.AreEqual(square(0),0); 
Assert.AreEqual(square(1),1); 
Assert.AreEqual(square(10),100); 
Assert.AreEqual(square(-1),1); 
Assert.AreEqual(square(-10),100); 
.... 
} 

Хорошо, может быть квадратом плохой пример :-)

В в каждом случае я проверяю ожидаемое поведение и все пограничные валы, такие как maxint и нуль и нулевое значение (помните, что вы также можете проверить на ошибки), и убедитесь, что тест не прошел (что не сложно :-)), тогда я продолжаю работать над до тех пор, пока он не будет работать.

Итак: сначала единичный тест, который не позволяет покрывать то, что вы хотите его покрыть, а затем метод.

Answer 7

Как правило, модульные тесты в «TDD» вообще не должны содержать никакого ввода-вывода.

Фактически, вы будете обладать большей эффективностью, если будете писать объекты, которые не создают побочных эффектов (I/O почти всегда, если не всегда, побочный эффект!) И определяют ваше поведение вашего класс либо с точки зрения возвращаемых значений методов, либо вызовы, сделанные для интерфейсов, которые были переданы в объект.

Answer 8

Я просто хочу рассказать о теме, которая может помочь понять TDD немного по-другому.

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

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

С другой стороны, TDD меняет ваше мышление, и я укажу один из таких способов. обычно вы просто полагаетесь на среду разработки, такую ​​как визуальная студия, чтобы обнаруживать ошибки при кодировании и компиляции и где-то в вашей голове, вы знаете это требование и просто кодируете и тестируете с помощью кнопок и всплывающих окон или проверки кода. Я называю этот стиль SDDD (синтаксическая отладочная разработка). , но когда вы делаете TDD, это «семантическая отладочная разработка», потому что вы сначала записываете свои мысли/цели своего приложения, используя тесты (которые и более динамичная и повторяемая версия белой доски), которая проверяет логику (или «семантический») вашего приложения и терпит неудачу всякий раз, когда у вас есть семантическая ошибка, даже если приложение передает синтаксическую ошибку (при компиляции).

Answer 9

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