Модульное тестирование

В компьютерном программировании , модульное тестирование является тестирование программного обеспечения метод , с помощью которого отдельные единицы исходного кода -множеств одного или нескольких компьютерных программных модулей вместе с соответствующими данными управления, использования процедур и операционных процедур, тестируют , чтобы определить , являются ли они пригодны для использования . ^[1]

Описание [ править ]

Модульные тесты обычно представляют собой автоматизированные тесты, написанные и выполняемые разработчиками программного обеспечения, чтобы гарантировать, что часть приложения (известная как «модуль») соответствует своему дизайну и ведет себя так, как задумано. ^[2] В процедурном программировании единицей может быть целый модуль, но чаще это отдельная функция или процедура. В объектно-ориентированном программировании единицей часто является целый интерфейс, например класс, но может быть и отдельный метод. ^[3] Написав тесты сначала для самых маленьких тестируемых модулей, а затем составного поведения между ними, можно создать комплексные тесты для сложных приложений. ^[2]

Чтобы изолировать проблемы, которые могут возникнуть, каждый тестовый пример следует тестировать независимо. Заменители, такие как заглушки методов , имитирующие объекты , ^[4] подделки и тестовые жгуты, могут использоваться для помощи в тестировании модуля изолированно.

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

Написание и сопровождение модульных тестов можно ускорить с помощью параметризованных тестов . Это позволяет выполнять один тест несколько раз с разными наборами входных данных, что сокращает дублирование кода теста. В отличие от традиционных модульных тестов, которые обычно представляют собой закрытые методы и инвариантные условия тестирования, параметризованные тесты принимают любой набор параметров. Параметризованные тесты поддерживаются TestNG , JUnit и его аналогом .Net, XUnit.. Подходящие параметры для модульных тестов могут быть предоставлены вручную или в некоторых случаях автоматически генерируются платформой тестирования. В последние годы была добавлена ​​поддержка для написания более мощных (модульных) тестов, использующих концепцию теорий, тестовых примеров, которые выполняют те же шаги, но с использованием тестовых данных, сгенерированных во время выполнения, в отличие от обычных параметризованных тестов, которые используют те же шаги выполнения с входными наборами. которые предопределены. ^{[5] [6] [7]}

Преимущества [ править ]

Цель модульного тестирования - изолировать каждую часть программы и показать, что отдельные части верны. ^[1] Модульный тест предоставляет строгий письменный контракт, которому должен удовлетворять фрагмент кода. В результате он дает несколько преимуществ.

Модульное тестирование обнаруживает проблемы на ранних этапах цикла разработки . Сюда входят как ошибки в реализации программиста, так и недостатки или отсутствующие части спецификации модуля. Процесс написания тщательного набора тестов вынуждает автора продумывать входные и выходные данные и условия ошибок и, таким образом, более четко определять желаемое поведение устройства. Стоимость обнаружения ошибки до начала кодирования или при первом написании кода значительно ниже, чем стоимость обнаружения, идентификации и исправления ошибки позже. Ошибки в выпущенном коде также могут вызвать дорогостоящие проблемы для конечных пользователей программного обеспечения. ^{[8] [9] [10]}Код может быть невозможным или трудным для модульного тестирования, если он плохо написан, поэтому модульное тестирование может заставить разработчиков лучше структурировать функции и объекты.

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

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

Модульное тестирование может уменьшить неопределенность самих модулей и может использоваться в подходе в стиле восходящего тестирования. Если сначала протестировать части программы, а затем проверить их сумму, интеграционное тестирование становится намного проще. ^{[ необходима цитата ]}

Модульное тестирование предоставляет своего рода живую документацию системы. Разработчики, которые хотят узнать, какие функции предоставляет модуль и как его использовать, могут взглянуть на модульные тесты, чтобы получить базовое представление об интерфейсе модуля ( API ). ^{[ необходима цитата ]}

Примеры модульных тестов включают характеристики, которые имеют решающее значение для успеха модуля. Эти характеристики могут указывать на уместное / несоответствующее использование отряда, а также на негативное поведение, которое отряд может уловить. Сам по себе пример модульного тестирования документирует эти критические характеристики, хотя многие среды разработки программного обеспечения не полагаются исключительно на код для документирования разрабатываемого продукта. ^{[ необходима цитата ]}

Когда программное обеспечение разрабатывается с использованием подхода, основанного на тестировании, сочетание написания модульного теста для определения интерфейса и действий по рефакторингу, выполняемых после прохождения теста, может занять место формального проектирования. Каждый модульный тест можно рассматривать как элемент дизайна, определяющий классы, методы и наблюдаемое поведение. ^{[ необходима цитата ]}

Ограничения и недостатки [ править ]

Тестирование не выявит каждую ошибку в программе, потому что оно не может оценить каждый путь выполнения в любой, кроме самых тривиальных программ. Эта проблема является надмножеством проблемы остановки , которая неразрешима . То же верно и для модульного тестирования. Кроме того, модульное тестирование по определению проверяет только функциональность самих модулей. Следовательно, он не будет обнаруживать ошибки интеграции или более широкие ошибки системного уровня (например, функции, выполняемые несколькими модулями, или нефункциональные области тестирования, такие как производительность ). Модульное тестирование следует проводить вместе с другим тестированием программного обеспечения.действия, так как они могут показать только наличие или отсутствие определенных ошибок; они не могут доказать полное отсутствие ошибок. Чтобы гарантировать правильное поведение для каждого пути выполнения и всех возможных входных данных, а также гарантировать отсутствие ошибок, требуются другие методы, а именно применение формальных методов для доказательства того, что программный компонент не имеет неожиданного поведения. ^{[ необходима цитата ]}

Сложная иерархия модульных тестов не означает интеграционное тестирование. Интеграцию с периферийными устройствами следует включать в интеграционные тесты, но не в модульные тесты. ^{[ необходима цитата ]} Интеграционное тестирование обычно по-прежнему в значительной степени зависит от ручного тестирования людей ; высокоуровневое или глобальное тестирование может быть сложно автоматизировать, поэтому ручное тестирование часто оказывается быстрее и дешевле. ^{[ необходима цитата ]}

Тестирование программного обеспечения - это комбинаторная проблема. Например, для каждого логического оператора решения требуется по крайней мере два теста: один с результатом «истина», а другой - с результатом «ложь». В результате для каждой написанной строки кода программистам часто требуется от 3 до 5 строк тестового кода. ^[11] Это, очевидно, требует времени, и его вложения могут не окупиться. Есть проблемы, которые вообще нелегко протестировать - например, недетерминированные или связанные с несколькими потоками . Кроме того, код для модульного теста, вероятно, будет содержать не меньше ошибок, чем код, который он тестирует. Фред Брукс в «Мифическом человеко-месяце» цитирует: «Никогда не выходите в море с двумя хронометрами; возьмите один или три». ^[12]То есть, если два хронометра противоречат друг другу, как узнать, какой из них правильный?

Еще одна проблема, связанная с написанием модульных тестов, - это сложность создания реалистичных и полезных тестов. Необходимо создать соответствующие начальные условия, чтобы тестируемая часть приложения вела себя как часть всей системы. Если эти начальные условия не установлены правильно, тест не будет использовать код в реалистичном контексте, что снижает ценность и точность результатов модульного тестирования. ^[13]

Чтобы получить ожидаемые выгоды от модульного тестирования, требуется строгая дисциплина на протяжении всего процесса разработки программного обеспечения. Важно вести тщательный учет не только проведенных тестов, но и всех изменений, которые были внесены в исходный код этого или любого другого модуля в программном обеспечении. Важно использовать систему контроля версий. Если более поздняя версия модуля не проходит определенный тест, который он ранее прошел, программное обеспечение контроля версий может предоставить список изменений исходного кода (если таковые имеются), которые были применены к модулю с того времени. ^{[ необходима цитата ]}

It is also essential to implement a sustainable process for ensuring that test case failures are reviewed regularly and addressed immediately.^[14] If such a process is not implemented and ingrained into the team's workflow, the application will evolve out of sync with the unit test suite, increasing false positives and reducing the effectiveness of the test suite.

Unit testing embedded system software presents a unique challenge: Because the software is being developed on a different platform than the one it will eventually run on, you cannot readily run a test program in the actual deployment environment, as is possible with desktop programs.^[15]

Unit tests tend to be easiest when a method has input parameters and some output. It is not as easy to create unit tests when a major function of the method is to interact with something external to the application. For example, a method that will work with a database might require a mock up of database interactions to be created, which probably won't be as comprehensive as the real database interactions.^{[16][better source needed]}

Example[edit]

Here is a set of test cases in Java that specify a number of elements of the implementation. First, that there must be an interface called Adder, and an implementing class with a zero-argument constructor called AdderImpl. It goes on to assert that the Adder interface should have a method called add, with two integer parameters, which returns another integer. It also specifies the behaviour of this method for a small range of values over a number of test methods.

import static org.junit.Assert.assertEquals;import org.junit.Test;public class TestAdder { @Test public void testSumPositiveNumbersOneAndOne() { Adder adder = new AdderImpl(); assertEquals(2, adder.add(1, 1)); } // can it add the positive numbers 1 and 2? @Test public void testSumPositiveNumbersOneAndTwo() { Adder adder = new AdderImpl(); assertEquals(3, adder.add(1, 2)); } // can it add the positive numbers 2 and 2? @Test public void testSumPositiveNumbersTwoAndTwo() { Adder adder = new AdderImpl(); assertEquals(4, adder.add(2, 2)); } // is zero neutral? @Test public void testSumZeroNeutral() { Adder adder = new AdderImpl(); assertEquals(0, adder.add(0, 0)); } // can it add the negative numbers -1 and -2? @Test public void testSumNegativeNumbers() { Adder adder = new AdderImpl(); assertEquals(-3, adder.add(-1, -2)); } // can it add a positive and a negative? @Test public void testSumPositiveAndNegative() { Adder adder = new AdderImpl(); assertEquals(0, adder.add(-1, 1)); } // how about larger numbers? @Test public void testSumLargeNumbers() { Adder adder = new AdderImpl(); assertEquals(2222, adder.add(1234, 988)); }}

In this case the unit tests, having been written first, act as a design document specifying the form and behaviour of a desired solution, but not the implementation details, which are left for the programmer. Following the "do the simplest thing that could possibly work" practice, the easiest solution that will make the test pass is shown below.

interface Adder { int add(int a, int b);}class AdderImpl implements Adder { public int add(int a, int b) { return a + b; }}

As executable specifications[edit]

Using unit-tests as a design specification has one significant advantage over other design methods: The design document (the unit-tests themselves) can itself be used to verify the implementation. The tests will never pass unless the developer implements a solution according to the design.

Unit testing lacks some of the accessibility of a diagrammatic specification such as a UML diagram, but they may be generated from the unit test using automated tools. Most modern languages have free tools (usually available as extensions to IDEs). Free tools, like those based on the xUnit framework, outsource to another system the graphical rendering of a view for human consumption.

Applications[edit]

Extreme programming[edit]

Unit testing is the cornerstone of extreme programming, which relies on an automated unit testing framework. This automated unit testing framework can be either third party, e.g., xUnit, or created within the development group.

Extreme programming uses the creation of unit tests for test-driven development. The developer writes a unit test that exposes either a software requirement or a defect. This test will fail because either the requirement isn't implemented yet, or because it intentionally exposes a defect in the existing code. Then, the developer writes the simplest code to make the test, along with other tests, pass.

Most code in a system is unit tested, but not necessarily all paths through the code. Extreme programming mandates a "test everything that can possibly break" strategy, over the traditional "test every execution path" method. This leads developers to develop fewer tests than classical methods, but this isn't really a problem, more a restatement of fact, as classical methods have rarely ever been followed methodically enough for all execution paths to have been thoroughly tested.^{[citation needed]} Extreme programming simply recognizes that testing is rarely exhaustive (because it is often too expensive and time-consuming to be economically viable) and provides guidance on how to effectively focus limited resources.

Crucially, the test code is considered a first class project artifact in that it is maintained at the same quality as the implementation code, with all duplication removed. Developers release unit testing code to the code repository in conjunction with the code it tests. Extreme programming's thorough unit testing allows the benefits mentioned above, such as simpler and more confident code development and refactoring, simplified code integration, accurate documentation, and more modular designs. These unit tests are also constantly run as a form of regression test.

Unit testing is also critical to the concept of Emergent Design. As emergent design is heavily dependent upon refactoring, unit tests are an integral component.^[17]

Unit testing frameworks[edit]

Unit testing frameworks are most often third-party products that are not distributed as part of the compiler suite. They help simplify the process of unit testing, having been developed for a wide variety of languages.

It is generally possible to perform unit testing without the support of a specific framework by writing client code that exercises the units under test and uses assertions, exception handling, or other control flow mechanisms to signal failure. Unit testing without a framework is valuable in that there is a barrier to entry for the adoption of unit testing; having scant unit tests is hardly better than having none at all, whereas once a framework is in place, adding unit tests becomes relatively easy.^[18] In some frameworks many advanced unit test features are missing or must be hand-coded.

Language-level unit testing support[edit]

Some programming languages directly support unit testing. Their grammar allows the direct declaration of unit tests without importing a library (whether third party or standard). Additionally, the boolean conditions of the unit tests can be expressed in the same syntax as boolean expressions used in non-unit test code, such as what is used for if and while statements.

Languages with built-in unit testing support include:

Some languages without built-in unit-testing support have very good unit testing libraries/frameworks. Those languages include:

See also[edit]

References[edit]

External links[edit]

• Test Driven Development (Ward Cunningham's Wiki)