The Art of Unit Testing / Искусство модульного тестирования: Part 1. Getting started

Раздел 1. С чего начать

Anthrax 10.04.14 в 16:09

В этом разделе книги описываются основы модульного тестирования.

Anthrax 10.04.14 в 16:11

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

Anthrax 10.04.14 в 16:22

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

Anthrax 10.04.14 в 17:16

Глава 1. Основы модульного тестирования

novmicha 10.04.14 в 18:14

Содержание главы:

novmicha 10.04.14 в 18:20

Определение юнит-теста

novmicha 10.04.14 в 18:16

Сравнение модульного и интеграционного тестирования

novmicha 10.04.14 в 18:18

Рассмотрение простого примера юнит-теста

novmicha 10.04.14 в 18:19

Понимание разработки через тестирование

novmicha 10.04.14 в 18:19

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

novmicha 10.04.14 в 18:40

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

novmicha 10.04.14 в 18:50

Давайте начнем с определения, что такое - модульные тесты.

dima117 10.04.14 в 20:17

1.1. Определение модульного тестирования - шаг за шагом

dima117 10.04.14 в 19:57

Модульное тестирование - не новая концепция в программировании. Оно появилось в первые дни программирования на Smalltalk в 70-х. Снова и снова оно показывает себя одним из лучших способов, с помощью которых разработчик может улучшить качество кода имея более глубокое понимание функциональных требований класса или метода.

dima117 10.04.14 в 19:50

Кент Бек ввел понятие модульного тестирования в Smalltalk и позже распространил его на другие языки программирования, сделав модульное тестирование - одной из самых полезных практик в разработке ПО. Прежде, чем двинуться дальше, нам нужно дать более четкое определение модульному тестированию. Ниже приведено классическое определение, из Википедии. Мы будем постепенно развивать и дополнять его в этой главе. Окончательный вариант определения появится в разделе 1,4,

dima117 10.04.14 в 19:56

Определение 1.0

dima117 10.04.14 в 19:50

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

dima117 10.04.14 в 20:25

Вещь, для которой пишутся модульные тесты, называется "тестируемая система" (SUT - system under test).

dima117 10.04.14 в 20:27

Определение

dima117 10.04.14 в 20:25

SUT расшифровывается как "system under test" - тестируемая система. Некоторые люди используют сокращение CUT - "class under test" (тестируемый класс) или "code under test" (тестируемый код). Когда вы тестируете что-то, SUT - это то, что вы тестируете.

dima117 11.04.14 в 07:55

Раньше я чувствовал (да, чувствовал - в этой книге нет науки, только искусство), что это определение модульного теста технически корректно, но за последние пару лет, мое понимание идеи модульных тестов сильно изменилось. Для меня блок является "единицей работы" или "прецедентом" ("user case") внутри системы.

dima117 11.04.14 в 08:00

Единица работы - это совокупность действий от вызова публичной функции до получение единственного значимого результата, который проверяется. Значимый результат может быть проверен без учета внутреннего состояния системы и только через публичные API системы и её поведение. Результат должен быть одним из:

nekalex 13.04.14 в 12:20

Вызываемый публичный метод возвращает значенначение (не void).

nekalex 13.04.14 в 12:04

Уведомление о смене внутреннего состояния или поведения системы, который определяется без просмотра внутреннего состояния. (Пример: система записывает в лог попытку авторизации или смену состояние системы, если это конечный автомат.)

nekalex 13.04.14 в 12:28

Вызов внешних систем, которые вы не контролируете. Эти внешние системы не игнарируют ваш запрос и возвращают не случайное значение. (Пример: вызов внешней системы логирования, которую вы не писали и у вас нет исходников этой системы).

nekalex 13.04.14 в 12:36

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

nekalex 13.04.14 в 12:41

Вы можете захотеть минимизировать единицу работы для тестов. Я так делал. Больше не делаю. Я верю, что можно создать такой большой модульный тест, что его результат будет более информативен пользователю вашей публичной API, такие тесты легче поддерживать. Если вы попытаетесь минимизировать единицу работы, вы сломаете себе мозг при разборе причин неизвестного результата публичной API, вместо того чтобы двигаться дальше. Эта тема будет развита сильнее, позже (в основном в 8 главе).

nekalex 13.04.14 в 13:11

Обновлённое определение 1.1

nekalex 13.04.14 в 12:43

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

nekalex 13.04.14 в 12:49

Не важно какой язык программирования вы используете, самое главное в модульных тестах - определить что такое "хорошо".

nekalex 13.04.14 в 12:56

1.1.1. О важности написания хороших модульных тестов

ChiFuka 11.04.14 в 06:58

Понимание единицы работы не достаточно.

nekalex 13.04.14 в 13:12

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

nekalex 13.04.14 в 13:21

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

nekalex 14.04.14 в 02:07

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

ChiFuka 11.04.14 в 07:01

Как вы можете убедиться что ваш код сегодня все еще работоспособен?

ChiFuka 11.04.14 в 07:02

1.1.2. Мы все пишем модульные тесты (вроде)

nekalex 14.04.14 в 01:54

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

nekalex 14.04.14 в 01:56

Вы можете использовать консольное приложение для проверки различных методов классов или компонентов, или создать специальный (WinForm, Web Form) пользовательский интерфейс, для проверки функциональности класса или компонента, или может быть каждый раз в ручную выполнять множество действия в реальном интерфейсе приложения. Конечный результат - код работает как надо или что-то еще.

nekalex 14.04.14 в 02:02

Рисунок 1.1. показывает, как большинство разработчиков проверяют свой код. Пользовательский интерфейс (UI) может меняться, но не меняется шаблон: ручной запуск внешнего инструмента для проверки чего либо снова или запуск приложения и проверка в ручную.

nekalex 14.04.14 в 01:59

Рисунок 1.1. В классическом тестировании, разработчик использует графический пользовательский интерфейс (GUI) для привязки действия к классу которой он проверяется. Потом он сравнивает результат.

nekalex 14.04.14 в 02:00

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

nekalex 14.04.14 в 02:05

1.2. Критерии хорошего модульного теста

ChiFuka 11.04.14 в 07:03

Модульный должен отвечать следующим критериям:

ChiFuka 11.04.14 в 07:04

Тест должен быть автоматизирован и воспроизводим.

ChiFuka 11.04.14 в 07:04

Тест должен быть прост в применении.

ChiFuka 11.04.14 в 07:05

Тест не должен терять актуальность в будущем.

ChiFuka 11.04.14 в 07:06

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

ChiFuka 11.04.14 в 07:08

Выполнение теста не должно занимать много времнеи.

ChiFuka 11.04.14 в 07:08