Модульное тестирование
| Часть серии о |
| Разработка программного обеспечения |
|---|
Модульное тестирование , также известное как тестирование компонентов или модулей , представляет собой форму тестирования программного обеспечения , при которой изолированный исходный код тестируется для проверки ожидаемого поведения. [1]
Модульное тестирование описывает тесты, которые выполняются на уровне модуля, в отличие от тестирования на уровне интеграции или системы .
История [ править ]
Модульное тестирование, как принцип отдельного тестирования небольших частей больших программных систем, восходит к заре разработки программного обеспечения. В июне 1956 года Х.Д. Бенингтон представил на симпозиуме ВМС США по передовым методам программирования для цифровых компьютеров проект SAGE и его подход, основанный на спецификациях, в котором за этапом кодирования следует «тестирование параметров» для проверки соответствия подпрограмм компонентов их спецификациям, за которым следует «тестирование параметров». сборочные испытания» для деталей, собранных вместе. [2] [3]
В 1964 году аналогичный подход описан для программного обеспечения проекта «Меркурий» , где отдельные блоки, разработанные разными программами, перед интеграцией вместе проходили «модульные испытания». [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 г. ) |
Во время разработки программист может закодировать в тесте критерии или заведомо хорошие результаты, чтобы проверить правильность устройства.
Во время выполнения теста платформы регистрируют тесты, которые не соответствуют какому-либо критерию, и сообщают о них в виде сводки.
Для этого наиболее часто используется подход «тест – функция – ожидаемое значение».
Тестовый пример [ править ]
Тестовый дубль [ править ]
Параметризованный тест [ править ]
Параметризованный тест — это тест, который принимает набор значений, которые можно использовать для запуска теста с несколькими разными входными значениями. Платформа тестирования, поддерживающая параметризованные тесты, поддерживает способ кодирования наборов параметров и запуска теста с каждым набором.
Использование параметризованных тестов может уменьшить дублирование тестового кода.
Параметризованные тесты поддерживаются TestNG , JUnit , [13] XUnit и NUnit , а также в различных средах тестирования JavaScript. [ нужна цитата ]
Параметры модульных тестов могут кодироваться вручную или, в некоторых случаях, автоматически генерироваться средой тестирования. В последние годы была добавлена поддержка написания более мощных (модульных) тестов с использованием концепции теорий и тестовых примеров, выполняющих те же шаги, но с использованием тестовых данных, сгенерированных во время выполнения, в отличие от обычных параметризованных тестов, которые используют одни и те же шаги выполнения с входными наборами. которые предопределены. [ нужна цитата ]
Гибкий [ править ]
Иногда при гибкой разработке программного обеспечения модульное тестирование проводится для каждой пользовательской истории и проводится во второй половине спринта после завершения сбора требований и разработки. Обычно разработчики или другие члены группы разработчиков, например консультанты , пишут пошаговые «тестовые сценарии», которые разработчики могут выполнить в инструменте. Тестовые сценарии обычно пишутся для подтверждения эффективной и технической работы конкретных разработанных функций инструмента, в отличие от полноценных бизнес-процессов, с которыми взаимодействует конечный пользователь , что обычно выполняется во время пользовательского приемочного тестирования . Если тестовый сценарий может быть полностью выполнен от начала до конца без происшествий, модульный тест считается «пройденным», в противном случае отмечаются ошибки, и пользовательская история возвращается в разработку в состоянии «в процессе». Пользовательские истории, успешно прошедшие модульные тесты, переходят к заключительным этапам спринта — проверке кода, экспертной оценке и, наконец, сеансу обратной связи, демонстрирующему разработанный инструмент заинтересованным сторонам.
Разработка через тестирование [ править ]
При разработке через тестирование (TDD) модульные тесты пишутся одновременно с написанием производственного кода. Начиная с рабочего кода, разработчик добавляет тестовый код для требуемого поведения, затем добавляет ровно столько кода, чтобы тест прошел, затем реорганизует код (включая тестовый код), если это имеет смысл, а затем повторяет действия, добавляя еще один тест.
Значение [ править ]
Модульное тестирование предназначено для того, чтобы убедиться, что модули соответствуют своей конструкции и ведут себя так, как задумано. [14]
Написав сначала тесты для наименьших тестируемых модулей, а затем составное поведение между ними, можно создать комплексные тесты для сложных приложений. [14]
Одна из целей модульного тестирования — изолировать каждую часть программы и показать, что отдельные части корректны. [1] Модульный тест представляет собой строгий письменный контракт , которому должен соответствовать фрагмент кода.
Раннее обнаружение проблем в цикле разработки [ править ]
Модульное тестирование выявляет проблемы на ранних этапах цикла разработки . Сюда входят как ошибки в реализации программиста, так и недостатки или недостающие части спецификации модуля. Процесс написания тщательного набора тестов заставляет автора продумывать входные и выходные данные и условия возникновения ошибок и, таким образом, более четко определять желаемое поведение устройства. [ нужна цитата ]
Сниженная стоимость [ править ]
Стоимость обнаружения ошибки до начала написания кода или при его первоначальном написании значительно ниже, чем стоимость обнаружения, идентификации и исправления ошибки позднее. Ошибки в выпущенном коде также могут вызвать дорогостоящие проблемы для конечных пользователей программного обеспечения. [15] [16] [17] Код может оказаться невозможным или трудным для модульного тестирования, если он плохо написан, поэтому модульное тестирование может заставить разработчиков лучше структурировать функции и объекты.
Более частые выпуски [ править ]
Модульное тестирование позволяет чаще выпускать выпуски при разработке программного обеспечения. Тестируя отдельные компоненты по отдельности, разработчики могут быстро выявлять и устранять проблемы, что приводит к ускорению циклов итерации и выпуска. [18]
Позволяет рефакторинг кода [ править ]
Модульное тестирование позволяет программисту провести рефакторинг позднее кода или обновить системные библиотеки и убедиться, что модуль по-прежнему работает корректно (например, при регрессионном тестировании ). Процедура заключается в написании тестовых примеров для всех функций и методов , чтобы любое изменение, вызывающее ошибку, можно было быстро выявить.
которые могут нарушить контракт на проектирование . Обнаруживает изменения ,
Модульные тесты обнаруживают изменения, которые могут нарушить контракт на проектирование .
Уменьшить неопределенность [ править ]
Модульное тестирование может снизить неопределенность в самих модулях и может использоваться в «снизу вверх» подходе тестирования . Если сначала протестировать части программы, а затем протестировать сумму ее частей, интеграционное тестирование становится намного проще. [ нужна цитата ]
Документация поведения системы [ править ]
Некоторые программисты утверждают, что модульные тесты представляют собой форму документирования кода. Разработчики, желающие узнать, какие функциональные возможности предоставляет модуль и как его использовать, могут просмотреть модульные тесты, чтобы получить представление о нем. [ нужна цитата ]
Тестовые случаи могут включать в себя характеристики, имеющие решающее значение для успеха модуля. Эти характеристики могут указывать на правильное/ненадлежащее использование единицы, а также на негативное поведение, которое должно быть уловлено единицей. Тестовый пример документирует эти важные характеристики, хотя многие среды разработки программного обеспечения не полагаются исключительно на код для документирования разрабатываемого продукта. [ нужна цитата ]
В некоторых процессах написание тестов и тестируемого кода, а также связанный с ним рефакторинг могут заменить формальное проектирование. Каждый модульный тест можно рассматривать как элемент дизайна, определяющий классы, методы и наблюдаемое поведение. [ нужна цитата ]
Ограничения и недостатки [ править ]
Тестирование не выявляет каждую ошибку в программе, поскольку оно не может оценить каждый путь выполнения ни в одной программе, кроме самых тривиальных. Эта проблема является расширенным вариантом проблемы остановки , которая неразрешима . То же самое справедливо и для модульного тестирования. Кроме того, модульное тестирование по определению проверяет только функциональность самих модулей. Таким образом, он не обнаруживает ошибки интеграции или более широкие ошибки системного уровня (например, функции, выполняемые несколькими модулями, или нефункциональные области тестирования, такие как производительность ). Модульное тестирование следует проводить в сочетании с другими видами деятельности по тестированию программного обеспечения , поскольку оно может показать только наличие или отсутствие определенных ошибок; они не могут доказать полное отсутствие ошибок. Чтобы гарантировать правильное поведение для каждого пути выполнения и каждого возможного ввода, а также гарантировать отсутствие ошибок, необходимы другие методы, а именно применение формальных методов для доказательства того, что программный компонент не имеет неожиданного поведения. [ нужна цитата ]
Сложная иерархия модульных тестов не равна интеграционному тестированию. Интеграцию с периферийными устройствами следует включать в интеграционные тесты, а не в модульные тесты. [ нужна цитата ] Интеграционное тестирование, как правило, по-прежнему в значительной степени зависит от ручного тестирования людьми ; Высокоуровневое или глобальное тестирование может быть сложно автоматизировать, поэтому ручное тестирование часто оказывается быстрее и дешевле. [ нужна цитата ]
Тестирование программного обеспечения — это комбинаторная задача. Например, для каждого логического утверждения решения требуется как минимум две проверки: одна с результатом «истина», а другая с результатом «ложь». В результате на каждую написанную строку кода программистам часто требуется от 3 до 5 строк тестового кода. [ нужна цитата ] Очевидно, что это требует времени, и вложения могут не стоить затраченных усилий. Существуют проблемы, которые вообще невозможно легко протестировать — например, те, которые недетерминированы или включают несколько потоков . Кроме того, код модульного теста может содержать ошибки так же, как и код, который он тестирует. Фред Брукс в «Мифическом человеко-месяце» цитирует: «Никогда не выходите в море с двумя хронометрами; возьмите один или три». [19] То есть, если два хронометра противоречат друг другу, как узнать, какой из них правильный?
Сложность в настройке реалистичных и полезных тестов [ править ]
Еще одна проблема, связанная с написанием модульных тестов, — это сложность создания реалистичных и полезных тестов. Необходимо создать соответствующие начальные условия, чтобы тестируемая часть приложения вела себя как часть всей системы. Если эти начальные условия заданы неправильно, тест не будет выполнять код в реалистичном контексте, что снижает ценность и точность результатов модульного теста. [ нужна цитата ]
Требует дисциплины на протяжении всего процесса разработки [ править ]
Чтобы получить желаемые преимущества от модульного тестирования, необходима строгая дисциплина на протяжении всего процесса разработки программного обеспечения.
Требуется контроль версий [ править ]
Крайне важно вести тщательный учет не только проведенных тестов, но и всех изменений, внесенных в исходный код того или иного модуля программного обеспечения. Использование системы контроля версий имеет важное значение. Если более поздняя версия модуля не проходит определенный тест, который она прошла ранее, программное обеспечение контроля версий может предоставить список изменений исходного кода (если таковые имеются), которые были применены к модулю с того времени. [ нужна цитата ]
Требует регулярных проверок [ править ]
Также важно внедрить устойчивый процесс, гарантирующий, что неудачные тестовые сценарии регулярно анализируются и немедленно устраняются. [20] Если такой процесс не будет реализован и не внедрен в рабочий процесс команды, приложение будет развиваться не синхронно с набором модульных тестов, что приведет к увеличению количества ложных срабатываний и снижению эффективности набора тестов.
Ограничения для встроенного системного программного обеспечения [ править ]
Модульное тестирование встроенного системного программного обеспечения представляет собой уникальную задачу: поскольку программное обеспечение разрабатывается на платформе, отличной от той, на которой оно в конечном итоге будет работать, вы не можете легко запустить тестовую программу в реальной среде развертывания, как это возможно с настольными программами. [21]
Ограничения для тестирования интеграции с внешними системами [ править ]
Юнит-тесты, как правило, проще всего, когда у метода есть входные параметры и некоторый результат. Не так просто создавать модульные тесты, когда основная функция метода — взаимодействие с чем-то внешним по отношению к приложению. Например, метод, который будет работать с базой данных, может потребовать создания макета взаимодействия с базой данных, который, вероятно, не будет таким полным, как реальные взаимодействия с базой данных. [22] [ нужен лучший источник ]
Примеры [ править ]
JUnit [ править ]
Ниже приведен пример набора тестов JUnit. Он фокусируется на Adder сорт.
класс Adder {
public int add ( int a , int b ) {
return a + b ;
}
}
Набор тестов использует утверждения утверждения для проверки ожидаемого результата различных входных значений в sum метод.
импортировать статический org.junit.Assert.assertEquals ;
импортировать org.junit.Test ;
общественный класс AdderUnitTest {
@Test
public void sumReturnsZeroForZeroInput () {
Adder adder = new Adder ();
AssertEquals ( 0 , adder . add ( 0 , 0 ));
}
@Test
public void sumReturnsSumOfTwoPositiveNumbers () {
Adder adder = новый Adder ();
AssertEquals ( 3 , adder . add ( 1 , 2 ));
}
@Test
public void sumReturnsSumOfTwoNegativeNumbers () {
Adder adder = новый Adder ();
AssertEquals ( -3 , adder.add ( -1 , ) -2 ; )
}
@Test
public void sumReturnsSumOfLargeNumbers () {
Adder adder = новый Adder ();
AssertEquals ( 2222 , adder.add ( , ) 1234 988 ; )
}
}
В качестве исполняемых спецификаций [ править ]
|
Использование модульных тестов в качестве спецификации проекта имеет одно существенное преимущество перед другими методами проектирования: документ проекта (сами модульные тесты) можно использовать для проверки реализации. Тесты никогда не пройдут, если разработчик не внедрит решение в соответствии с дизайном.
Модульному тестированию не хватает доступности диаграммной спецификации, такой как диаграмма UML , но они могут быть созданы из модульного теста с использованием автоматизированных инструментов. Большинство современных языков имеют бесплатные инструменты (обычно доступные в виде расширений для IDE ). Бесплатные инструменты, например, основанные на платформе xUnit , передают другой системе графическую визуализацию представления для потребления человеком.
Приложения [ править ]
Экстремальное программирование [ править ]
Модульное тестирование является краеугольным камнем экстремального программирования , которое опирается на автоматизированную структуру модульного тестирования . Эта автоматизированная среда модульного тестирования может быть либо сторонней, например, xUnit , либо создана внутри группы разработчиков.
Экстремальное программирование использует создание модульных тестов для разработки через тестирование . Разработчик пишет модульный тест, который выявляет либо требования к программному обеспечению, либо дефект. Этот тест завершится неудачно, потому что либо требование еще не реализовано, либо потому, что он намеренно выявляет дефект в существующем коде. Затем разработчик пишет простейший код, обеспечивающий прохождение теста и других тестов.
Большая часть кода в системе подвергается модульному тестированию, но не обязательно все пути прохождения кода. Экстремальное программирование требует стратегии «проверять все, что может сломаться» вместо традиционного метода «проверять каждый путь выполнения». Это заставляет разработчиков разрабатывать меньше тестов, чем классические методы, но на самом деле это не проблема, а скорее повторение факта, поскольку классические методы редко когда-либо применялись достаточно методично, чтобы все пути выполнения были тщательно протестированы. [ нужна цитата ] Экстремальное программирование просто признает, что тестирование редко бывает исчерпывающим (поскольку оно зачастую слишком дорого и отнимает много времени, чтобы быть экономически жизнеспособным), и дает рекомендации о том, как эффективно сосредоточить ограниченные ресурсы.
Важно отметить, что тестовый код считается первоклассным артефактом проекта, поскольку он поддерживается на том же уровне, что и код реализации, без всякого дублирования. Разработчики выпускают код модульного тестирования в репозиторий кода вместе с тестируемым им кодом. Тщательное модульное тестирование экстремального программирования обеспечивает упомянутые выше преимущества, такие как более простая и уверенная разработка и рефакторинг кода , упрощенная интеграция кода, точная документация и более модульные конструкции. Эти модульные тесты также постоянно запускаются как форма регрессионного теста .
Модульное тестирование также имеет решающее значение для концепции Emergent Design . Поскольку эмерджентный дизайн во многом зависит от рефакторинга, модульные тесты являются неотъемлемым компонентом. [ нужна цитата ]
Платформы автоматизированного тестирования [ править ]
Платформа автоматизированного тестирования предоставляет функции для автоматизации выполнения тестов и может ускорить написание и выполнение тестов. Фреймворки были разработаны для широкого спектра языков программирования .
Как правило, фреймворки являются сторонними ; не распространяется вместе с компилятором или интегрированной средой разработки (IDE).
Тесты можно писать без использования инфраструктуры для проверки тестируемого кода с использованием утверждений , обработки исключений и других механизмов потока управления для проверки поведения и сообщения об ошибках. Некоторые отмечают, что тестирование без фреймворка ценно, поскольку существует барьер для внедрения фреймворка; Лучше иметь несколько тестов, чем ничего, но как только структура создана, добавлять тесты может быть проще. [23]
В некоторых платформах расширенные функции тестирования отсутствуют, и их приходится программировать вручную.
языка модульного тестирования на Поддержка уровне
Некоторые языки программирования напрямую поддерживают модульное тестирование. Их грамматика позволяет напрямую объявлять модульные тесты без импорта библиотеки (сторонней или стандартной). Кроме того, логические условия модульных тестов могут быть выражены в том же синтаксисе, что и логические выражения, используемые в коде немодульных тестов, например, то, что используется для if и while заявления.
Языки со встроенной поддержкой модульного тестирования включают:
Языки со стандартной поддержкой платформы модульного тестирования включают:
Некоторые языки не имеют встроенной поддержки модульного тестирования, но имеют установленные библиотеки или платформы модульного тестирования. К этим языкам относятся:
См. также [ править ]
- Приемочное тестирование
- Характеристический тест
- Компонентное юзабилити-тестирование
- Предикаты проектирования
- Проектирование по договору
- Экстремальное программирование
- Функциональное тестирование
- Интеграционное тестирование
- Список фреймворков модульного тестирования
- Регрессионное тестирование
- Программная археология
- Тестирование программного обеспечения
- Тестирование системы
- Прецедент
- Разработка через тестирование
- xUnit — семейство фреймворков модульного тестирования.
Ссылки [ править ]
- ^ Перейти обратно: а б Колава, Адам; Хейзинга, Дорота (2007). Автоматизированное предотвращение дефектов: лучшие практики управления программным обеспечением . Издательство компьютерного общества Wiley-IEEE. п. 75. ИСБН 978-0-470-04212-0 .
- ^ Бенингтон, Герберт Д. (1956). «Производство больших компьютерных программ». Материалы симпозиума по передовым методам программирования для цифровых компьютеров, Вашингтон, округ Колумбия, 28-29 июня 1956 г. Управление военно-морских исследований Военно-морского ведомства: 15–28.
- ^ Перейти обратно: а б Бенингтон, HD (1 марта 1987 г.). «Производство больших компьютерных программ (перепечатка статьи 1956 года с обновленным предисловием)» . Материалы 9-й Международной конференции по программной инженерии . МЦБИ '87. Вашингтон, округ Колумбия, США: Издательство компьютерного общества IEEE: 299–310. ISBN 978-0-89791-216-7 .
- ^ Донеган, Джеймс Дж.; Паккард, Кальвин; Пэшби, Пол (1 января 1964 г.). «Опыт использования вычислительной системы Годдарда во время пилотируемых космических полетов» . Материалы 19-й национальной конференции ACM 1964 года . АКМ '64. Нью-Йорк, штат Нью-Йорк, США: Ассоциация вычислительной техники. С. 12.101–12.108. дои : 10.1145/800257.808889 . ISBN 978-1-4503-7918-2 .
- ^ Циммерман, Норман А. (26 августа 1969 г.). «Системная интеграция как функция программирования» . Материалы 24-й национальной конференции 1969 года . АКМ '69. Нью-Йорк, штат Нью-Йорк, США: Ассоциация вычислительной техники. стр. 459–467. дои : 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. дои : 10.1145/1007775.811118 . ISSN 0163-5999 .
- ^ Гулати, Шекхар (2017). Модульное тестирование Java с помощью JUnit 5: разработка через тестирование с помощью JUnit 5 . Рахул Шарма. Беркли, Калифорния: Apress. п. 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(Е). 1 декабря 2010 г. стр. 1–418. дои : 10.1109/IEESTD.2010.5733835 . ISBN 978-0-7381-6205-8 .
- ^ Канер, Джем (май 2003 г.). «Что такое хороший тестовый пример?» (PDF) . ЗВЕЗДА Востока : 2.
- ^ Гулати и Шарма 2017 , стр. 133–137, глава §7 Модель расширения JUnit 5 — параметризованный тест.
- ^ Перейти обратно: а б Хэмилл, Пол (2004). Фреймворки модульного тестирования: инструменты для разработки высококачественного программного обеспечения . O'Reilly Media, Inc. ISBN 9780596552817 .
- ^ Бём, Барри В .; Папаччо, Филип Н. (октябрь 1988 г.). «Понимание и контроль затрат на программное обеспечение» (PDF) . Транзакции IEEE по разработке программного обеспечения . 14 (10): 1462–1477. дои : 10.1109/32.6191 . Архивировано из оригинала (PDF) 9 октября 2016 года . Проверено 13 мая 2016 г.
- ^ «Тестируйте рано и часто» . Майкрософт.
- ^ «Докажите, что это работает: использование Unit Test Framework для тестирования и проверки программного обеспечения» . Национальные инструменты . 21 августа 2017 г.
- ^ Эрик (10 марта 2023 г.). «Вы все еще не знаете, как проводить модульное тестирование (и ваш секрет в безопасности со мной)» . Стекировать . Проверено 10 марта 2023 г.
- ^ Брукс, Фредерик Дж. (1995) [1975]. Мифический человеко-месяц . Аддисон-Уэсли. п. 64 . ISBN 978-0-201-83595-3 .
- ^ даВейга, Нада (6 февраля 2008 г.). «Изменяйте код без страха: используйте систему регрессионной безопасности» . Проверено 8 февраля 2008 г.
- ^ Кучарски, Марек (23 ноября 2011 г.). «Практическое использование модульного тестирования для встраиваемых систем» . Проверено 20 июля 2020 г.
- ^ «Юнит-тесты и базы данных» . Проверено 29 января 2024 г.
- ^ Технология тестирования «яблочко» (2006–2008 гг.). «Промежуточные цели охвата» . Проверено 24 марта 2009 г.
- ^ «Юнит-тесты — язык программирования D» . D Язык программирования . Языковой фонд D. Проверено 5 августа 2017 г.
- ^ Стив Клабник и Кэрол Николс при участии сообщества Rust (2015–2023 гг.). «Как писать тесты» . Проверено 21 августа 2023 г.
- ^ «Кристалл Спец» . Crystal-lang.org . Проверено 18 сентября 2017 г.
- ^ «тестирование — язык программирования Go» . golang.org . Проверено 3 декабря 2013 г.
- ^ «Модульное тестирование · Язык Джулии» . docs.julialang.org . Проверено 15 июня 2022 г.
- ^ Документация Python (2016). «unittest — среда модульного тестирования» . Проверено 18 апреля 2016 г.
- ^ Валлийский, Ноэль; Калпеппер, Райан. «RackUnit: Модульное тестирование» . ПЛТ Дизайн Инк . Проверено 26 февраля 2019 г.
- ^ Валлийский, Ноэль; Калпеппер, Райан. «Пакет RackUnit Unit Testing, входящий в основной дистрибутив Racket» . ПЛТ Дизайн Инк . Проверено 26 февраля 2019 г.
- ^ «Минитест (Рубин 2.0)» . Руби-Док.org.
- ^ Сьерра, Стюарт. «API для clojure.test — Clojure v1.6 (стабильный)» . Проверено 11 февраля 2015 г.
- ^ «Пестер Фреймворк» . Гитхаб . Проверено 28 января 2016 г.
Дальнейшее чтение [ править ]
- Перья, Майкл К. (2005). Эффективная работа с устаревшим кодом . Аппер-Сэддл-Ривер, Нью-Джерси: Профессиональный технический справочник Прентис-Холла. ISBN 978-0131177055 .
- Гулати, Шекхар; Шарма, Рахул (2017). Модульное тестирование Java с помощью JUnit 5 . Апресс .