Dunit unit testing framework что это

Обновлено: 06.07.2024

Системное тестирование (system testing) — тест высокого уровня для проверки работы большего куска приложения или системы в целом.

Регрессионное тестирование (regression testing) — тестирование, которое используется для проверки того, не влияют ли новые фичи или исправленные баги на существующий функционал приложения и не появляются ли старые баги.

Функциональное тестирование (functional testing) — проверка соответствия части приложения требованиям, заявленным в спецификациях, юзерсторях и т. д.

Виды функционального тестирования:

тест «белого ящика» (white box) на соответствие части приложения требованиям со знанием внутренней реализации системы;
тест «черного ящика» (black box) на соответствие части приложения требованиям без знания внутренней реализации системы.

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

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

Integration — интеграционное тестирование. Оно проверяет более крупные кусочки системы, то есть это либо объединение нескольких кусочков логики (несколько методов или классов), либо корректность работы с внешним компонентом. Этих тестов как правило меньше, чем Unit, так как они тяжеловеснее.

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

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

Сегодня подробно рассмотрим самые используемые тесты — юнит-тесты, так как уметь ими пользоваться на базовом уровне должны все уважающие себя Java-разработчики.

Ключевые понятия юнит-тестирования

материал о Code Coverage на JavaRush и на Хабре; .

Пишем наш тест.
Запускаем тест, прошел он или нет (видим, что всё красное — не психуем: так и должно быть).
Добавляем код, который должен удовлетворить данный тест (запускаем тест).
Выполняем рефакторинг кода.

Этапы тестирования

Задание тестируемых данных (фикстур).
Использование тестируемого кода (вызов тестируемого метода).
Проверка результатов и сверка с ожидаемыми.

Среды тестирования

assertEquals(Object expecteds, Object actuals) — проверяет, равны ли передаваемые обьекты.
assertTrue(boolean flag) — проверяет, возвращает ли переданное значение — true.
assertFalse(boolean flag) — проверяет, возвращает ли переданное значение — false.
assertNull(Object object) – проверяет, является ли объект нулевым (null).
assertSame(Object firstObject, Object secondObject) — проверяет, ссылаются ли передаваемые значения на один и тот же обьект.
assertThat(T t, Matcher<T> matcher) — проверяет, удовлетворяет ли t условию, указанному в matcher.

Практика тестирования

А теперь давайте рассмотрим приведенный выше материал на конкретном примере. Будем тестировать метод для сервиса — update. Рассматривать слой дао не будем, так как он у нас дефолтный. Добавим стартер для тестов: Итак, класс сервиса: 8 — вытягиваем обновляемый обьект из БД 9-14 — создаём объект через билдер, если в приходящем объекте есть поле — задаем его, если нет — оставляем то, что есть в БД И смотрим наш тест: 1 — наш Runner 4 — изолируем сервис от слоя дао, подставляя мок 11 — задаем для класса тестовую сущность (ту, которую мы будем юзать в качестве испытуемого хомячка) 22 — задаём объект сервиса, который мы и будем тестить Здесь мы видим четкое разделение теста на три части: 3-9 — задание фикстур 11 — выполнение тестируемой части 13-17 — проверка результатов Подробнее: 3-4 — задаём поведение для мока дао 5 — задаём экземпляр, который мы будем апдейтить поверх нашего стандартного 11 — используем метод и берём результирующий экземпляр 13 — проверяем, что он не ноль 14 — сверяем айди результата и заданные аргументы метода 15 — проверяем, обновилось ли имя 16 — смотрим результат по cpu 17 – так как в экземпляре для обновления мы не задавали это поле, оно должно остаться прежним, проверяем это. Запускаем: Тест зелёный, можно выдыхать)) Итак, подведём итоги: тестирование улучшает качество кода и делает процесс разработки более гибким и надёжный. Представьте себе, как много сил мы потратим при изменении дизайна программного обеспечения с сотнями файлов классов. Когда у нас есть модульные тесты, написанные для всех этих классов, мы можем уверенно провести рефакторинг. И самое главное — это помогает нам легко находить ошибки во время разработки. Гайз, на этом у меня сегодня всё: сыпем лайки, пишем комменты)))

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

Доказательство корректности кода

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

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

Отличие от других видов тестов

Все вышесказанное справедливо для любых тестов. Там даже не упомянуты юнит-тесты как таковые. Итак, в чем же их отличие?

Ответ кроется в названии: «юнит» означает, что мы тестируем не всю систему в целом, а небольшие ее части. Мы проводим тестирование с высокой гранулярностью.

25–26 ноября, Москва и онлайн, От 24 000 до 52 000 ₽

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

И все-таки, что такое юнит?

Часто встречается мнение, что юнит — это класс. Однако это не всегда верно. Например, в C++, где классы не обязательны.

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

Юнит — это маленький самодостаточный участок кода, реализующий определенное поведение, который часто (но не всегда) является классом.

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

Отсутствие сцепления необходимо для написания юнит-тестов.

Другие применения юнит-тестов

Кроме доказательства корректности, у юнит-тестов есть еще несколько применений.

Тесты как документация

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

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

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

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

При разработке через тестирование (test-driven development, TDD) вы сначала пишете тесты, которые проверяют поведение вашего кода. При запуске они, конечно, провалятся (или даже не скомпилируются), поэтому ваша задача — написать код, который проходит эти тесты.

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

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

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

Возможность лучше разобраться в коде

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

Разработка через тестирование в Delphi производится с помощью встроенного инструмента DUnit. В статье мы рассмотрим, как создаются тестовые проекты Delphi, как создавать юнит тесты и как тестировать.

Итак, сначала поговорим о том, что такое DUnit. DUnit – это инструмент тестирования с открытыми исходными кодами, основанный на JUnit. Доступен он как для Delphi, так и для C++.

Вообще, в состав Delphi этот инструмент включён начиная с Delphi 2005. Для Delphi и C++ Builder DUnit устанавливается автоматически установщиком RAD Studio. В папке \source\DUnit (внутри папки, куда установлен Delphi) вы можете найти много ресурсов, в том числе исходные файлы, документацию и примеры тестов. Поставляется DUnit под лицензией Mozilla Public License 1.1 (MPL).

В статье я не буду углубляться в теорию, а лишь покажу, как пользоваться инструментом DUnit в Delphi. Будем считать, что читатель знает, что такое разработка через тестирование.

Создание тестового проекта

Тестовый проект содержит один или несколько тестовых случаев, которые представляют из себя обычные .pas файлы и будут доступны в IDE на панели Project Manager. Также RAD Studio предоставляет в ваше распоряжение мастер создания тестового проекта «Test Project Wizard». Рекомендуется создавать два отдельных проекта: один тестируемый, а второй тестирующий. Так вам не придётся в будущем удалять ваши тесты из готового приложения.

Давайте для начала создадим проект, который мы будем тестировать. Допустим, это будет оконное VCL приложение. Выберите пункт меню «File -> New -> VCL Forms Application - Delphi». Созданный проект сохраните.

После создания тестируемого проекта, создадим тестовый проект. Для этого выберите пункт меню «File -> New -> Other. », затем в диалоге «New Items» выберите «Unit Test -> Test Project» и нажмите «OK».

На первом шаге мастера «Test Project Wizard» в поле «Source Project» можно указать тестируемый проект, если их несколько. В полях «Project Name» и «Location» указывается название и расположение тестового проекта. В поле «Personality» выбирается язык программирования (в нашем случае – это Delphi). Все перечисленные поля заполнились автоматически, что нам подходит. Галочку «Add to project group» оставьте, чтобы проект добавился в текущую группу проектов. Нажмите «Next >».

На следующем шаге можно выбрать, как будет выполняться тест (поле «Test Runner»): в окне («GUI») или в консоли («Console»). Оставим здесь предложенный по умолчанию вариант – «GUI». В поле «Test Framework» указываются инструменты тестирования. Поменять в этом поле ничего нельзя, т.к. для Delphi и C++ поддерживается только инструмент DUnit. Нажмите «Finish» и вы увидите, что в группе проектов появился новый пустой тестовый проект.

Тестовые случаи и тестирование

В типичном тестовом проекте, для каждого тестируемого класса есть тестирующий класс, но это не обязательно. Тестирующий класс также привязан к тестовому случаю. Как правило, тестирующий класс имеет набор из одного или нескольких методов, которые соответствуют одному или нескольким методам тестируемого класса. В один тестовый проект могут быть включены несколько тестовых случаев. Запуск каждого тестового случая и тестового проекта может быть автоматизирован с помощью bat-файлов или скриптов сборки проекта.

В основном рекомендуется создавать тесты в отдельном проекте (отдельно от тестируемого проекта). Так вам не нужно будет удалять тесты из проекта перед финальной сборкой проекта.

RAD Studio предоставляет вам мастер «Test Case Wizard» для помощи в создании тестовых случаев, которые вы сможете настроить на своё усмотрение.

Прежде чем сделать тестовый случай, давайте определимся, что мы будем тестировать. В тестируемом проекте Project1, который мы создали, есть форма. Давайте её и будем тестировать. Допустим, наша форма будет построчно сравнивать два текстовых файла и показывать строки с различиями. Сравнивать будем двумя способами: учитывая регистр и без учёта регистра. Код для теста сделаем элементарный, будем сравнивать строки с одинаковыми индексами.

Итак, на форму ставим два текстовых поля TRichEdit и две кнопки TButton. Затем обрабатываем события от нажатий кнопок и дописываем код следующим образом:

Как видите, по нажатию на кнопки будут вызываться две процедуры Compare и ShowDifferences. Первая процедура будет сравнивать два текста и сохранять индексы несовпадающих строк в список differentStrings, а вторая процедура будет на основе этого списка подкрашивать несовпадающие строки в красный цвет. В процедуру Compare будет передаваться параметр ignoreCase определяющий способ сравнения строк. Пока реализацию функции Compare делать не будем, а сразу сделаем тест для неё.

Для создания тестов нужно сделать следующие шаги:

- - - Откройте юнит, для которого нужно сделать тесты и переключитесь на закладку «Code». Т.е. ваш юнит должен отображаться в редакторе кода.
    - Выберите пункт меню «File -> New -> Other. ».
    - В диалоге «New Items» выберите «Unit Tests -> Test Case» и нажмите «OK».
    - - В открывшемся мастере «Test Case Wizard» на первом шаге нужно указать путь к файлу тестируемого юнита в поле «Source file» (сюда автоматически подставляется путь к файлу для текущего открытого в редакторе юнита) и выбрать, какие классы и методы нам нужно тестировать. В нашем примере будем тестировать только один метод Compare, поэтому поставьте галочку только напротив него. Нажмите «Next >».
        
        После этого вы увидите, что в тестовом проекте появился файл «TestUnit1.pas» и в этот же проект добавлен тестируемый юнит «Unit1.pas».
        
        А вот что вы увидите в файле TestUnit1.pas:
        
        Как видите, здесь сделана заготовка для тестирующего класса TestTForm1, унаследованного от класса TTestCase. В секции initialization происходит регистрация этого класса.
        
        В методе SetUp происходит подготовка к тестированию. Здесь нужно создать тестируемый класс и подготовить всё что нужно для тестов, например, подключиться к удалённому серверу или базе данных и т.п. Кстати здесь код сгенерирован с ошибкой: конструктор формы должен принимать входной параметр. Исправим строку кода с созданием формы следующим образом:
        
        Метод TearDown вызывается по окончании тестирования и здесь нужно освободить все ресурсы и удалить все созданные объекты. Здесь сгенерированный код нас устраивает.
        
        Метод TestCompare создан как раз для тестирования нашего метода Compare. Как видите, здесь вызывается наш метод Compare, но нет никаких проверок. Давайте добавим здесь в текстовые поля одинаковый текст, вызовем метод Compare и сделаем проверку результата.
        
        После этого запустите тестовый проект Project1Tests.exe. Для этого сделайте его активным (дважды щёлкните по проекту в окошке «Project Manager») и затем запустите его выполнение (для этого выберите пункт меню «Run -> Run» или нажмите клавишу F9). После запуска перед вами появится окошко, показанное на картинке ниже.
        
        Чтобы запустить все тесты выберите пункт меню «Actions -> Run». Если у вас много тестов, а вам нужно выполнить только часть из них, вы можете проставить галочки рядом с нужными тестами и затем вызвать пункт меню «Actions -> Run selected test». После выполнения тестов вы увидите нашу ошибку. Это нормально, ведь пока наша функция Compare не написана и она ничего не сравнивает. Если вы щёлкните на ошибку, то в нижнем поле увидите подробности.
        
        Теперь давайте исправлять ошибки, чтобы тестирование прошло успешно. Допишите функцию сравнения следующим образом:
        
        В методе тестирования добавим тесты для разных вариантов сравнения:
        
        Теперь протестируем нашу функцию Compare. Как видите, всё работает правильно, ошибок нет.
        
        Помимо метода CheckEquals в вашем распоряжении есть и другие методы для проверки результатов. Вот основные методы, которые вам могут понадобиться:
        
        Check – проверяет выполнение условия и кидает исключение, если условие не выполняется.
        
        CheckEquals – проверяет равенство двух значений и кидает исключение, если значения не равны.
        
        CheckNotEquals – проверяет неравенство двух значений и кидает исключение, если значения равны.
        
        CheckNotNull – проверяет указатель на «не nil» и кидает исключение, если указатель равен nil.
        
        CheckNull – проверяет указатель на nil и кидает исключение, если указатель не равен nil.
        
        CheckSame – проверяет равенство указателей на объекты и кидает исключение, если указатели не равны.
        
        Fail – просто кидает исключение ETestFailure с нужным вам текстом.
        
        Тестирование приватных методов
        
        Отдельно хотелось бы показать, как тестировать приватные методы. Для вызова приватных методов в Delphi мы воспользуемся RTTI (Run-Time Type Information).
        
        Для начала перенесите объявление переменной differentStrings и методов Compare и ShowDifferences в секцию private и добавьте директиву $RTTI, которая даст доступ к приватным методам (к приватным переменным доступ через RTTI разрешён по умолчанию):
        
        Код тестирования поменяйте следующим образом, не забыв добавить в секцию uses юнит System.Rtti:
        
        Аналогично можно тестировать приватные свойства. Директива $RTTI будет выглядеть тогда следующим образом:
        
        Итак, из статьи вы узнали, как реализована поддержка разработки с помощью тестирования в Delphi, а именно: как создавать тестовый проект, как создавать тесты и проводить тестирование, как тестировать приватные методы.
        
        Модульное тестирование сегодня применяется самым активным образом для практически всех языков программирования, за очень редким исключением. И на это есть свои причины. Давайте поговорим сейчас о модульном тестировании более подробно.
        
        Введение
        
        В позапрошлом номере "Компьютерных вестей" мы с вами уже достаточно подробно обсудили разные виды тестов, которым подвергаются приложения, перед тем как станут пригодны для "выхода в люди". Не буду повторять содержание той статьи - если кто-то захочет, её очень просто найти на сайте нашей газеты. Так вот, среди прочих видов тестов там упоминалось и модульное тестирование, которое по-английски называется unit testing, ну и по-русски, соответственно, пишется и говорится нередко именно как unit-тестирование.
        
        Идея, лежащая в основе модульного тестирования, заключается в отдельном тестировании поведения каждой самостоятельной единицы программного кода. Поскольку сейчас программный код в подавляющем большинстве пишется на объектно-ориентированных языках, то в качестве "кирпичика" кода выступает написанный программистом класс, а если переходить на ещё более глубокий уровень, то даже не класс, а отдельно взятый метод этого класса.
        
        Unit-тесты для своего кода пишут сами программисты. Одним из преимуществ модульного тестирования является возможность выявления ошибок на ранних этапах разработки самим разработчиком. Это, конечно, несколько увеличивает нагрузку на разработчика, но позволяет здорово сэкономить время на отладке готового кода приложения, а также даёт ещё целый ряд преимуществ, которые мы обсудим подробнее чуть ниже. Нужно сказать, что "писать unit-тесты" в наше продвинутое в технологическом плане время вовсе не означает писать их совершенно самостоятельно, что называется, "с нуля". Потому что существует масса специализированных библиотек и фреймворков для тестирования, позволяющих если не на все 100%, то по крайней мере очень и очень значительно автоматизировать создание модульных тестов для приложений, которые пишутся на самых разных языках программирования. Об этих фреймворках - не обо всех, конечно, а о самых известных, потому как всех в одной статье ну никак не упомянуть, - мы ещё немного поговорим чуть дальше.
        
        Как это выглядит на практике?
        
        Сам по себе тест - это какая-то функция/метод, сначала вызывающая другие функции/методы, которые и нужно протестировать, а затем сравнивающая возвращаемые ими значения с эталоном. Обычно в рамках одного теста моделируется широкий спектр входных данных для тестируемой функции - чтобы быть уверенным, что она будет вести себя как положено при любых значениях входных параметров. Эту функцию потом вызывают в рамках автоматического "прогона" тестов по коду.
        
        Итак, как же выглядит применение unit-тестирования на практике? В зависимости от выбранной методологии разработки программного обеспечения применение unit-тестов в, так сказать, производственном процессе может выглядеть по-разному. Интереснее всего с точки зрения применения модульных тестов выглядит подход, который называется "разработкой через тестирование" (test-driven development). Особенность данного подхода состоит в том, что тесты при этом пишутся ещё до написания основного кода. Да-да, согласен, это выглядит достаточно необычно, если вы ни разу не сталкивались ни с чем подобным ранее, однако если подумать, то всё не так и странно, как кажется поначалу.
        
        Дело в том, что до написания самого программного кода, который нужно тестировать, тесты, конечно же, работать не будут. Но никто и не говорит, что они должны работать до этого - задача написания тестов до создания тестируемого кода заключается в конкретизации требований к тестируемым классам и методам. После того, как разработаны тесты и написан "каркас" кода, по которому эти тесты уже можно "прогонять", стоит приступать к написанию самого кода. При этом задача программиста состоит в том, чтобы написать такой код, который успешно "продерётся" через тернии всевозможных тестов и будет при этом отвечать заранее разработанным спецификациям.
        
        Хотя в написании тестов ещё до разработки кода нет технологически обусловленной необходимости, многие рассматривают именно такой порядок работы с тестами как одно из необходимых условий их успешного применения. Дело в том, что каждый unit-тест удорожает стоимость разработки (ведь, как минимум, несколько её удлиняет). Таким образом, чтобы тест был написан не зря (и время не его написание не ушло впустую), нужно, чтобы это тест хотя бы раз не был выполнен успешно. Если разработчик пишет тесты ещё до основного кода, то шанс, что тест "завалится", намного выше, чем когда тест разрабатывается после самого кода, и разработчик уже знает, как именно может его код отреагировать на те или иные моменты, а потому и немного "похимичить" с тестом, чтобы он был правильным всегда - то есть неэффективным.
        
        Разработка с таким подходом как бы усложняется и становится длиннее, что в ряде случаев может не понравиться заказчику. Но при этом убиваются некоторые дополнительные зайцы, что уже выглядит как плюс для того программиста или для той конторы, в которой применяется test-driven development. Давайте посмотрим вместе, что даёт использование этой методики разработки программ.
        
        Плюсы и минусы unit-тестирования
        
        Как и всё в нашем несовершенном мире, модульное тестирование имеет не только плюсы, но и минусы. Но сначала давайте всё-таки о плюсах, потому что иначе, прочитав о минусах, многие просто бросят эту статью и не узнают о том, чем unit-тесты полезны.
        
        Во-первых, модульное тестирование позволяет быть уверенным, что из-за исправления одного бага у вас не появился другой. Поскольку тесты работают в автоматическом режиме, вы всегда можете отследить описанную выше ситуацию (проведя, тем самым, регрессионное тестирование). Ещё один плюс, который, по большому счёту, группируется с первым, - unit-тесты позволяют безболезненно проводить рефакторинг кода (то есть изменение самого кода без какого бы то ни было изменения его функциональности). Многие даже утверждают, что модульные тесты поощряют рефакторинг кода разработчиками.
        
        Второй плюс заключается в том, что unit-тесты служат некоторым образом документацией к коду и путеводителем по нему. И вправду, тесты могут рассказать, как та или иная функции должны реагировать на разные входные параметры - описание этого поведения зачастую по не вполне объяснимым причинам (все понимают, что основная причина - лень и работа в режиме "это нужно было реализовать ещё вчера") отсутствует в комментариях, оставляемых программистами.
        
        Третий плюс состоит в том, что применение unit-тестов даёт более качественное отделение интерфейса от реализации. Поскольку в рамках одного теста проверяется один класс, то все "порочные" связи с другими классами, не предусмотренные архитектурой приложения, всплывают на поверхность и безжалостным образом разрываются.
        
        Теперь давайте и о минусах. Первые минус - вполне логичное продолжение последнего плюса. Если вы тестируете каждый элемент программного кода в отдельности от других, никто не сможет сказать наверняка, что произойдёт, когда вы всю эту кучу-малу смешаете воедино. То есть, пардон, не смешаете, а интегрируете в единое целое. Поэтому не обойтись без дополнительных интеграционных тестов.
        
        Но это ещё полбеды. Следующий минус заключается в том, что при недостаточно продуманной архитектуре проекта тесты могут мешать изменению кода, а не способствовать ему. Ситуация не такая уж и редкая, а потому и далеко не последняя в списке неприятностей.
        
        Но хуже всего то, что даже тесты, успешно выполненные и перевыполненные после внесения всяческих изменений, не дают никакой гарантии, что в коде нет ошибок. И дело здесь даже не в подгонке тестов под код, а в пресловутом человеческом факторе. Иногда несколько изменив значения входных параметров в рамках тестов программист может, сам того не желая, пропустить ошибку в тестируемом коде или, хуже того, внести её туда. Но, увы и ах, от ошибок, связанных с человеческим фактором, не застрахован никто и никогда.
        
        Инструменты
        
        Выше я упоминал, что есть специальные инструменты, которые помогают программисту писать unit-тесты, и даже пообещал упомянуть некоторые из них. Что ж, выполняю это обещание.
        
        Резюме
        
        Что ж, как видите, в самой идее unit-тестирования нет ничего сложного. Да и в практике, пожалуй, тоже. Нужно только найти где-то время и силы на изучение тестировочного фреймворка для используемого вами языка программирования и для того, чтобы писать сами тесты. А время, особенно время программиста, - ресурс, как известно, весьма и весьма дефицитный. Впрочем, возможно, из прочитанного выше вы почерпнули, что время, потраченное на unit-тесты, того стоит. Остаётся только пожелать вам успехов в их освоении и применении.
        
        Читайте также:
        
        
        Как отключить субтитры на нетфликс на ноутбуке
        
        Сыпет тонер epson c1100
        
        Пари матч как войти через компьютер
        
        Не видит hdd после установки ssd
        
        Настройка параметров безопасности opera