ЕДИНЦИОННЫЕ Тестирование
| Часть серии на |
| Разработка программного обеспечения |
|---|
Единое тестирование , известное как компонентное или модульное тестирование, является формой тестирования программного обеспечения, с помощью которой изолированный исходный код тестируется для проверки ожидаемого поведения. [ 1 ]
Единое тестирование описывает тесты, которые выполняются на уровне единицы, чтобы контрастировать тестирование на интеграции или системном уровне.
История
[ редактировать ]Единое тестирование, как принцип для тестирования отдельно меньшими частями крупных программных систем, восходит к первым дням разработки программного обеспечения. В июне 1956 года HD Benington представил на Симпозиуме ВМС США о передовых методах программирования цифровых компьютеров проект SAGE и его подход, основанный на спецификации, где за этапом кодирования последовало «тестирование параметров» для проверки подпрограмм компонентов против их спецификации, затем затем « Сборка тестирования "для деталей, собранных. [ 2 ] [ 3 ]
В 1964 году аналогичный подход описан для программного обеспечения проекта Mercury , где отдельные подразделения, разработанные различными программами, прошли «модульные тесты», прежде чем интегрироваться вместе. [ 4 ] В 1969 году методологии тестирования кажутся более структурированными, с модульными тестами, компонентными тестами и интеграционными тестами с целью проверки отдельных частей, записанных отдельно, и их прогрессивной сборки в более крупные блоки. [ 5 ] Некоторые публичные стандарты приняли конец 60-х годов, такие как MIL-STD-483 [ 6 ] и MIL-STD-490 способствовал широкому признанию единичных тестирования в крупных проектах.
Модульные тестирование было в те времена интерактивные [ 3 ] или автоматизированный, [ 7 ] Используя либо кодированные тесты, либо инструменты тестирования и воспроизведения . В 1989 году Кент Бек описал структуру тестирования для SmallTalk (позже называется SUNIT ) в « Простых тестирования SmallTalk: с узорами ». В 1997 году Кент Бек и Эрих Гамма разработали и выпустили Junit , модульную тестовую рамку, которая стала популярной у разработчиков Java . [ 8 ] Google принял автоматическое тестирование около 2005–2006 годов. [ 9 ]
Единица
[ редактировать ]Единица определяется как единственное поведение, демонстрируемое тестируемой системой (SUT), обычно соответствующей требованию. Хотя это может означать, что это функция или модуль (в процедурном программировании ) или метод или класс (в объектно-ориентированном программировании ), это не означает, что функции/методы, модули или классы всегда соответствуют единицам. С точки зрения систем, только периметр системы является актуальным, таким образом, только вход указывает на внешнее системное поведение определяет единицы. [ 10 ]
Исполнение
[ редактировать ]Модульные тесты могут быть выполнены вручную или с помощью автоматического выполнения тестов . Автоматизированные тесты включают в себя такие преимущества, как: часто проводя тесты, проводя тестов без кадровых расходов, а также последовательные и повторяемые тестирование.
Тестирование часто выполняется программистом, который пишет и изменяет тестируемый код. Единое тестирование может быть просмотрено как часть процесса написания кода.
Критерии тестирования
[ редактировать ] | В этом разделе нужны дополнительные цитаты для проверки . ( Сентябрь 2019 ) |
Во время разработки программист может кодировать критерии или результаты, которые, как известно, являются хорошими, в тест, чтобы проверить правильность устройства.
Во время выполнения теста тесты журнала Frameworks , которые проваливают любой критерий, и сообщают об их резюме.
Для этого наиболее часто используемым подходом является тест - функция - ожидаемое значение.
Тестовый случай
[ редактировать ]Тест двойной
[ редактировать ]Параметризованный тест
[ редактировать ]Параметризованный тест - это тест, который принимает набор значений, которые можно использовать для того, чтобы тест мог работать с несколькими, различными входными значениями. Структура тестирования, которая поддерживает параметризованные тесты, поддерживает способ кодирования наборов параметров и запустить тест с каждым набором.
Использование параметризованных тестов может уменьшить дублирование тестового кода.
Параметризованные тесты поддерживаются Testng , Junit , [ 13 ] XUNIT и NUNIT , а также в различных фреймворках JavaScript. [ Цитация необходима ]
Параметры для модульных тестов могут быть закодированы вручную или в некоторых случаях, автоматически генерируются тестовой структурой. В последние годы была добавлена поддержка для написания более мощных (единичных) тестов, используя концепцию теорий, тестовые случаи, которые выполняют те же шаги, но с использованием тестовых данных, сгенерированных во время выполнения, в отличие от обычных параметризованных тестов, которые используют те же шаги выполнения с наборами входных которые предварительно определен. [ Цитация необходима ]
Гибкий
[ редактировать ]Иногда при разработке Agile Software проводятся модульные тестирование на историю пользователя и поступают в более поздней половине спринта после завершения сбора требований и разработки. Как правило, разработчики или другие члены команды разработчиков, такие как консультанты , будут писать пошаговые «тестовые сценарии» для разработчиков, чтобы разработчики могли выполнять в инструменте. Тестовые сценарии, как правило, записываются, чтобы доказать эффективную и техническую работу конкретных разработанных функций в инструменте, в отличие от полноценных бизнес -процессов, которые будут связаны с конечным пользователем , который обычно выполняется во время тестирования приема пользователя . Если тестовый фонд может быть полностью выполнен от начала до конца без инцидентов, считается, что модульный тест считается «пройденным», в противном случае отмечены ошибки, и история пользователя возвращается к разработке в состоянии «в прогрессе». Пользовательские истории, которые успешно проходят модульные тесты, перемещаются на последние этапов обзора Sprint - Code, рассмотрения сверстников, а затем, наконец, сессией «выставки», демонстрирующего разработанный инструмент для заинтересованных сторон.
Тестовая разработка
[ редактировать ]В разработке тестирования (TDD) модульные тесты написаны во время написания производственного кода. Начиная с рабочего кода, разработчик добавляет тестовый код для требуемого поведения, затем добавляет достаточно кода, чтобы сделать тестовый проход, а затем рефракциировать код (включая тестовый код), как это имеет смысл, а затем повторяется, добавив еще один тест.
Ценить
[ редактировать ]Единое тестирование предназначено для обеспечения того, чтобы подразделения соответствовали своей конструкции и ведут себя в соответствии с задумами. [ 14 ]
Сначала написав тесты для самых маленьких тестируемых единиц, затем составное поведение между ними, можно создать комплексные тесты для сложных приложений. [ 14 ]
Одной из целей единичного тестирования является выделение каждой части программы и показать, что отдельные части правильны. [ 1 ] Единый тест содержит строгий письменный договор , который должен удовлетворить кусок кода.
Раннее обнаружение проблем в цикле разработки
[ редактировать ]Единое тестирование обнаруживает проблемы в начале цикла разработки . Это включает в себя обе ошибки в реализации и недостатках программиста или отсутствующие части спецификации для устройства. Процесс написания тщательного набора тестов заставляет автора продумать входные данные, выходы и условия ошибки, и, таким образом, более четко определять желаемое поведение устройства. [ Цитация необходима ]
Снижение стоимости
[ редактировать ]Стоимость поиска ошибки до начала кодирования или когда код сначала записан, значительно ниже, чем стоимость обнаружения, выявления и исправления ошибки позже. Ошибки в выпущенном коде могут также вызвать дорогостоящие проблемы для конечных пользователей программного обеспечения. [ 15 ] [ 16 ] [ 17 ] Код может быть невозможным или трудным для единичного тестирования, если плохо записан, поэтому модульное тестирование может заставить разработчиков структурировать функции и объекты в лучшем виде.
Более частые выпуски
[ редактировать ]Единое тестирование обеспечивает более частые выбросы в разработку программного обеспечения. Тестируя отдельные компоненты в изоляции, разработчики могут быстро идентифицировать и решать проблемы, что приводит к более быстрой итерации и циклам высвобождения. [ 18 ]
Разрешает рефакторинг кода
[ редактировать ]Единое тестирование позволяет программисту код рефакторирования или обновления системных библиотек на более позднем возрасте и убедиться, что модуль все еще работает правильно (например, в регрессионном тестировании ). Процедура состоит в том, чтобы написать тестовые примеры для всех функций и методов , чтобы всякий раз, когда изменение вызывает ошибку, его можно было быстро идентифицировать.
Обнаружает изменения, которые могут сломать контракт на проектирование
[ редактировать ]Модульные тесты обнаруживают изменения, которые могут сломать конструктивный контракт .
Уменьшить неопределенность
[ редактировать ]Единое тестирование может снизить неопределенность в самих единицах и может использоваться в подходе в стиле тестирования снизу вверх . Сначала тестируя части программы, а затем тестируя сумму ее частей, интеграционное тестирование становится намного проще. [ Цитация необходима ]
Документация поведения системного поведения
[ редактировать ]Некоторые программисты утверждают, что модульные тесты предоставляют форму документации кода. Разработчики, желающие узнать, какие функции предоставляются единицей, и как его использовать, могут просмотреть модульные тесты, чтобы получить его понимание. [ Цитация необходима ]
Тестовые случаи могут воплощать характеристики, которые имеют решающее значение для успеха блока. Эти характеристики могут указывать на соответствующее/ненадлежащее использование единицы, а также негативное поведение, которое должно быть поймано на единицу. Тестовый пример документирует эти критические характеристики, хотя многие среды разработки программного обеспечения не полагаются исключительно на код, чтобы документировать продукт в разработке. [ Цитация необходима ]
В некоторых процессах, акт письменных тестов и тестирование кода, плюс связанный рефакторинг, могут занять место формального проекта. Каждый модульный тест можно рассматривать как элемент дизайна, определяющий классы, методы и наблюдаемое поведение. [ Цитация необходима ]
Ограничения и недостатки
[ редактировать ]Тестирование не пойдет на каждую ошибку в программе, потому что оно не может оценить каждый путь выполнения в любых, кроме самых тривиальных программ. Эта проблема является суперсетом проблемы с остановкой , которая неразрешима . То же самое верно для модульного тестирования. Кроме того, модульное тестирование по определению только проверяет функциональность самих единиц. Следовательно, он не будет улавливать ошибки интеграции или более широкие ошибки на уровне системы (например, функции, выполняемые в нескольких единицах, или нефункциональные области тестирования, такие как производительность ). Единое тестирование должно проводиться в сочетании с другими видами тестирования программного обеспечения , поскольку они могут показывать только наличие или отсутствие определенных ошибок; Они не могут доказать полное отсутствие ошибок. Чтобы гарантировать правильное поведение для каждого пути выполнения и каждого возможного ввода, и обеспечить отсутствие ошибок, требуются другие методы, а именно применение формальных методов , чтобы доказать, что программный компонент не имеет неожиданного поведения. [ Цитация необходима ]
Сложная иерархия модульных тестов не равна тестированию интеграции. Интеграция с периферическими единицами должна быть включена в интеграционные тесты, но не в модульные тесты. [ Цитация необходима ] Интеграционное тестирование, как правило, все еще в значительной степени зависит от тестирования людей вручную ; Высокоуровневое тестирование или глобальное тестирование может быть трудно автоматизировать, так что ручное тестирование часто кажется быстрее и дешевле. [ Цитация необходима ]
Программное обеспечение является комбинаторной проблемой. Например, каждое логическое заявление о решении требует как минимум двух тестов: один с результатом «истинного» и один с результатом «false». В результате для каждой строки написанных кода программисты часто нуждаются в 3-5 строках тестового кода. [ Цитация необходима ] Это, очевидно, требует времени, и его инвестиции могут не стоить усилий. Существуют проблемы, которые не могут быть легко проверены вообще - например, те, которые являются нетерминированными или включают несколько потоков . Кроме того, код для модульного теста так же может быть глюком, как и код, который он тестирует. Фред Брукс в мифическом человеке-месячном цитатах: «Никогда не ходите в море с двумя хронометрами; возьмите один или три». [ 19 ] Это означает, что если два хронометра противоречат, как вы узнаете, какой из них правильный?
Сложность в создании реалистичных и полезных тестов
[ редактировать ]Еще одна проблема, связанная с написанием модульных тестов, - это сложность настройки реалистичных и полезных тестов. Необходимо создать соответствующие начальные условия, чтобы часть тестируемого приложения ведет себя как часть полной системы. Если эти начальные условия не установлены правильно, тест не будет осуществлять код в реалистичном контексте, который снижает значение и точность результатов модульного теста. [ Цитация необходима ]
Требует дисциплины на протяжении всего процесса разработки
[ редактировать ]Чтобы получить предполагаемые преимущества от модульного тестирования, в процессе разработки программного обеспечения необходима строгая дисциплина.
Требуется контроль версий
[ редактировать ]Важно вести тщательные записи не только проведенных тестов, но и всех изменений, которые были сделаны в исходном коде этого или любой другой единицы в программном обеспечении. Использование системы управления версиями очень важно. Если более поздняя версия устройства проходит конкретный тест, который он ранее прошел, программное обеспечение для контроля версии может предоставить список изменений исходного кода (если таковые имеются), которые были применены к устройству с тех пор. [ Цитация необходима ]
Требует регулярных обзоров
[ редактировать ]Также важно реализовать устойчивый процесс для обеспечения регулярного пересмотра тестового случая и немедленно рассмотрены. [ 20 ] Если такой процесс не реализован и укоренился в рабочем процессе команды, приложение будет развиваться из синхронизации с набором модульных тестов, увеличивая ложные позитивы и снижая эффективность тестового набора.
Ограничения для встроенного системного программного обеспечения
[ редактировать ]Встроенное системное программное обеспечение модуля представляет собой уникальную проблему: поскольку программное обеспечение разрабатывается на другой платформе, чем на той, на которой он в конечном итоге будет работать, вы не можете легко запустить тестовую программу в фактической среде развертывания, как это возможно с помощью программ настольных компьютеров. [ 21 ]
Ограничения для тестирования интеграции с внешними системами
[ редактировать ]Модульные тесты имеют тенденцию быть самыми простыми, когда метод имеет входные параметры и некоторые выводы. Не так просто создавать модульные тесты, когда основной функцией метода является взаимодействие с чем -то внешним по отношению к приложению. Например, метод, который будет работать с базой данных, может потребовать макета взаимодействий с базами данных, что, вероятно, не будет таким полным, как реальные взаимодействия базы данных. [ 22 ] [ Лучший источник необходим ]
Примеры
[ редактировать ]Юнит
[ редактировать ]Ниже приведен пример испытательного пакета JUNIT. Фокусируется на Adder сорт.
class Adder {
public int add(int a, int b) {
return a + b;
}
}
Тестовый набор использует операторы ASSERT для проверки ожидаемого результата различных входных значений в sum метод
import static org.junit.Assert.assertEquals;
import org.junit.Test;
public class AdderUnitTest {
@Test
public void sumReturnsZeroForZeroInput() {
Adder adder = new Adder();
assertEquals(0, adder.add(0, 0));
}
@Test
public void sumReturnsSumOfTwoPositiveNumbers() {
Adder adder = new Adder();
assertEquals(3, adder.add(1, 2));
}
@Test
public void sumReturnsSumOfTwoNegativeNumbers() {
Adder adder = new Adder();
assertEquals(-3, adder.add(-1, -2));
}
@Test
public void sumReturnsSumOfLargeNumbers() {
Adder adder = new Adder();
assertEquals(2222, adder.add(1234, 988));
}
}
Как исполняемые спецификации
[ редактировать ] |
Использование единичных тестов в качестве спецификации проектирования имеет одно существенное преимущество перед другими методами проектирования: проектный документ (сами единичные тесты) можно само по себе использовать для проверки реализации. Тесты никогда не пройдут, если разработчик не реализует решение в соответствии с дизайном.
В модульном тестировании не хватает некоторой доступности диаграммной спецификации, такой как диаграмма UML , но они могут быть сгенерированы из модульного теста с использованием автоматизированных инструментов. У большинства современных языков есть бесплатные инструменты (обычно доступные в качестве расширений для IDE ). Бесплатные инструменты, например, на основе структуры XUNIT , аутсорсируют другую систему, графическое визуализацию взгляда на потребление человеком.
Приложения
[ редактировать ]Чрезвычайное программирование
[ редактировать ]Единое тестирование является краеугольным камнем экстремального программирования , который опирается на плату автоматизированного модульного тестирования . Эта структура автоматического модульного тестирования может быть третьей стороной, например, XUNIT или создана в группе разработки.
Extreme Programming использует создание модульных тестов для тестовых разработок . Разработчик записывает модульный тест, который раскрывает либо программное требование, либо дефект. Этот тест потерпит неудачу, потому что либо требование еще не выполнено, либо потому, что он намеренно выявляет дефект в существующем коде. Затем разработчик пишет самый простой код, чтобы пройти тест вместе с другими тестами.
Большая часть кода в системе проверяется, но не обязательно все пути через код. Экстремальное программирование предписывает стратегию «Проверьте все, что может сломать», по сравнению с традиционным методом «Проверка каждого пути выполнения». Это заставляет разработчиков разрабатывать меньше тестов, чем классические методы, но на самом деле это не проблема, а скорее повторное действие, так как классические методы редко когда -либо методично следуют, чтобы все пути выполнения были тщательно протестированы. [ Цитация необходима ] Экстремальное программирование просто признает, что тестирование редко исчерпывающее (потому что часто слишком дорого и трудоемким, чтобы быть экономически жизнеспособным) и дает руководство о том, как эффективно сосредоточиться на ограниченных ресурсах.
Важно отметить, что тестовый код считается первым классовым артефактом проекта в том смысле, что он поддерживается на том же качеством, что и код реализации, при этом все дублирование удаляется. Разработчики выпускают код тестирования модуля в репозиторий кода в сочетании с тестированием кода. Тщательное модульное тестирование Extreme Programming позволяет упомянуть выше преимущества, такие как более простая и более уверенная разработка кода и рефакторинг , упрощенная интеграция кода, точная документация и более модульные конструкции. Эти модульные тесты также постоянно выполняются как форма регрессионного теста .
Единое тестирование также имеет решающее значение для концепции возникающего дизайна . Поскольку возникающая конструкция в значительной степени зависит от рефакторинга, модульные тесты являются неотъемлемым компонентом. [ Цитация необходима ]
Автоматизированное тестирование
[ редактировать ]Автоматизированная структура тестирования предоставляет функции для автоматизации выполнения тестирования и может ускорить написание и запуск тестов. Рамки были разработаны для широкого спектра языков программирования .
Как правило, фреймворки являются сторонними ; не распространяется с помощью компилятора или интегрированной среды разработки (IDE).
Тесты могут быть записаны без использования структуры для использования тестирования кода с использованием утверждений , обработки исключений и других механизмов управления потоком для проверки поведения и отказа от неудачи. Некоторые отмечают, что тестирование без структуры является ценным, поскольку существует барьер для входа для принятия структуры; То, что наличие некоторых тестов лучше, чем ничего, но после того, как структура на месте, добавление тестов может быть проще. [ 23 ]
В некоторых фреймворках усовершенствованные тестовые функции отсутствуют и должны быть вручную кодировку.
Поддержка для тестирования на языковом уровне
[ редактировать ]Некоторые языки программирования непосредственно поддерживают модульные тестирование. Их грамматика позволяет прямую объявление модульных тестов без импорта библиотеки (будь то третья сторона или стандартная). Кроме того, логические условия модульных тестов могут быть выражены в том же синтаксисе, что и логические выражения, используемые в тестовом коде, не являющемся UNIT, например, что используется для if и while заявления.
Языки со встроенной поддержкой модульного тестирования включают:
Языки со стандартной поддержкой модульного тестирования включают в себя:
Некоторые языки не имеют встроенной поддержки единичного тестирования, но имеют установленные библиотеки или фреймворки модуля. Эти языки включают:
- Абап
- C ++
- C#
- Клоджюр [ 33 ]
- Эликсир
- Ява
- JavaScript
- Объектив-c
- Перв
- PHP
- PowerShell [ 34 ]
- R с Testthat
- Скала
- TCL
- Visual Basic .net
- Xojo с Xojounit
Смотрите также
[ редактировать ]- Приемное тестирование
- Тест характеристики
- Компонентное удобство удобства использования
- Дизайн предикатов
- Дизайн по контракту
- Чрезвычайное программирование
- Функциональное тестирование
- Интеграционное тестирование
- Список модульных структур
- Регрессионное тестирование
- Программная археология
- Программное тестирование
- Системное тестирование
- Тестовый случай
- Тестовая разработка
- XUNIT - семейство модульных фреймворков.
Ссылки
[ редактировать ]- ^ Jump up to: а беременный Колава, Адам; Huizinga, Dorota (2007). Автоматизированное предотвращение дефектов: лучшие практики в области управления программным обеспечением . Wiley-Ieee Computer Society Press. п. 75. ISBN 978-0-470-04212-0 .
- ^ Бенингтон, Герберт Д. (1956). «Производство крупных компьютерных программ». Материалы симпозиума по передовым методам программирования для цифровых компьютеров, Вашингтон, округ Колумбия, 28-29 июня 1956 года . Управление военно -морских исследований, Департамент флота: 15–28.
- ^ Jump up to: а беременный Бенингтон, HD (1 марта 1987 г.). «Производство крупных компьютерных программ (перепечатка бумаги 1956 года с обновленным предисловием)» . Материалы 9 -й Международной конференции по разработке программного обеспечения . ICSE '87. Вашингтон, округ Колумбия, США: IEEE Computer Society Press: 299–310. ISBN 978-0-89791-216-7 .
- ^ Донеган, Джеймс Дж.; Паккард, Кальвин; Пашби, Пол (1 января 1964 г.). «Опыт работы с Годдардской вычислительной системой во время пилотируемых миссий космического полета» . Материалы 1964 г. Национальной конференции ACM . ACM '64. Нью -Йорк, штат Нью -Йорк, США: Ассоциация по компьютерной технике. С. 12.101–12.108. doi : 10.1145/800257.808889 . ISBN 978-1-4503-7918-2 .
- ^ Циммерман, Норман А. (26 августа 1969 г.). «Системная интеграция как функция программирования» . Материалы 24 -й национальной конференции 1969 года . ACM '69. Нью -Йорк, штат Нью -Йорк, США: Ассоциация по компьютерной технике. С. 459–467. doi : 10.1145/800195.805951 . ISBN 978-1-4503-7493-4 .
- ^ MIL-STD-483 Военный стандарт: методы управления конфигурацией для систем, оборудования, боеприпасов и компьютерных программ . Соединенные Штаты, Министерство обороны. 31 декабря 1970 года. С. Раздел 3.4.7.2.
Подрядчик должен затем кодировать и тестировать единицы программного обеспечения, а также ввести исходный код и объектный код, а также связанные списки каждого успешно протестированного устройства в конфигурацию разработки
{{cite book}}: Cs1 Maint: дата и год ( ссылка ) - ^ Тиг, Майкл Ф. (1 января 1978 г.). «Ценность правильной методологии обеспечения качества программного обеспечения» . Обзор оценки эффективности ACM Sigmetrics . 7 (3–4): 165–172. doi : 10.1145/1007775.811118 . ISSN 0163-5999 .
- ^ Гулати, Шехар (2017). Java Unit Testing с JUNIT 5: Тестовая разработка с 5 JUNIT 5 . Рахул Шарма. Беркли, Калифорния: Апресс. п. 8. ISBN 978-1-4842-3015-2 Полем OCLC 1012347252 .
- ^ Уинтерс, Титус (2020). Программное обеспечение в Google: уроки, извлеченные из программирования с течением времени . Том Маншрек, Хайрум Райт (1 -е изд.). Себастополь, Калифорния: О'Рейли. ISBN 978-1-4920-8274-3 Полем OCLC 1144086840 .
- ^ Бек, Кент (2002). Тестовая разработка по примеру . Аддисон-Уэсли. ISBN 978-0321146533 .
- ^ Системные и программные разработки - словарный запас . ISO/IEC/IEEE 24765: 2010 (E). 1 декабря 2010 года. С. 1–418. doi : 10.1109/ieeestd.2010.5733835 . ISBN 978-0-7381-6205-8 .
- ^ Канер, CEM (май 2003 г.). "Что такое хороший тестовый пример?" (PDF) . Звездный восток : 2.
- ^ Gulati & Sharma 2017 , с. 133–137, глава §7 Модель расширения Junit 5 - Параметризованный тест.
- ^ Jump up to: а беременный Хэмилл, Пол (2004). Модульные тестовые рамки: инструменты для высококачественной разработки программного обеспечения . O'Reilly Media, Inc. ISBN 9780596552817 .
- ^ Boehm, Barry W . ; Папаччо, Филипп Н. (октябрь 1988 г.). «Понимание и контроль затрат на программное обеспечение» (PDF) . IEEE транзакции на разработке программного обеспечения . 14 (10): 1462–1477. doi : 10.1109/32.6191 . Архивировано из оригинала (PDF) 9 октября 2016 года . Получено 13 мая 2016 года .
- ^ «Тестируй рано и часто» . Microsoft.
- ^ «Докажите, что он работает: использование модульной тестовой структуры для тестирования и проверки программного обеспечения» . Национальные инструменты . 21 августа 2017 года.
- ^ Эрик (10 марта 2023 г.). «Вы до сих пор не знаете, как провести модульное тестирование (и ваш секрет в безопасности со мной)» . Stackify . Получено 10 марта 2023 года .
- ^ Брукс, Фредерик Дж. (1995) [1975]. Мифический человек-мужчина . Аддисон-Уэсли. п. 64 ISBN 978-0-201-83595-3 .
- ^ Давига, ничего (6 февраля 2008 г.). «Изменить код без страха: используйте сеть безопасности регрессии» . Получено 8 февраля 2008 года .
- ^ Кучарски, Марек (23 ноября 2011 г.). «Создание модульного тестирования практичным для встроенного развития» . Получено 20 июля 2020 года .
- ^ «Модульные тесты и базы данных» . Получено 29 января 2024 года .
- ^ Технология тестирования Bullseye (2006–2008). «Промежуточные цели охвата» . Получено 24 марта 2009 г.
- ^ «Модульные тесты - D язык программирования» . D Язык программирования . D языковой фонд . Получено 5 августа 2017 года .
- ^ Стив Клабник и Кэрол Николс, с вкладами сообщества Rust (2015–2023). «Как писать тесты» . Получено 21 августа 2023 года .
- ^ "Crystal Spec" . Crystal-lang.org . Получено 18 сентября 2017 года .
- ^ «Тестирование - язык программирования GO» . Golang.org . Получено 3 декабря 2013 года .
- ^ «Единое тестирование · Язык Юлии» . docs.julialang.org . Получено 15 июня 2022 года .
- ^ Документация Python (2016). «Unittest - модульная структура тестирования» . Получено 18 апреля 2016 года .
- ^ Уэльс, Ноэль; Калпеппер, Райан. «RackUnit: модульное тестирование» . PLT Design Inc. Получено 26 февраля 2019 года .
- ^ Уэльс, Ноэль; Калпеппер, Райан. «Пакет пакета блок -блок растворта часть основного распределения ракетки» . PLT Design Inc. Получено 26 февраля 2019 года .
- ^ "Minitest (Ruby 2.0)" . Ruby-Doc.org.
- ^ Сьерра, Стюарт. «API для clojure.test - clojure v1.6 (стабильный)» . Получено 11 февраля 2015 года .
- ^ «Пестер -каркас» . GitHub . Получено 28 января 2016 года .
Дальнейшее чтение
[ редактировать ]- Перья, Майкл С. (2005). Эффективно работать с устаревшим кодом . Верхняя Седл -Ривер, Нью -Джерси: Prentice Hall Профессиональная техническая ссылка. ISBN 978-0131177055 .
- Гулати, Шехар; Шарма, Рахул (2017). Java Unit Testing с 5 Junit 5 . Апресс .