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

Поделись знанием:
Это текущая версия страницы, сохранённая Mercury (обсуждение | вклад) в 18:01, 26 сентября 2016. Вы просматриваете постоянную ссылку на эту версию.

(разн.) ← Предыдущая | Текущая версия (разн.) | Следующая → (разн.)
Перейти к: навигация, поиск

Модульное тестирование, или юнит-тестирование (англ. unit testing) — процесс в программировании, позволяющий проверить на корректность отдельные модули исходного кода программы.

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

Преимущества

Цель модульного тестирования — изолировать отдельные части программы и показать, что по отдельности эти части работоспособны.

Этот тип тестирования обычно выполняется программистами.

Поощрение изменений

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

Упрощение интеграции

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

Документирование кода

Модульные тесты можно рассматривать как «живой документ» для тестируемого класса. Клиенты, которые не знают, как использовать данный класс, могут использовать юнит-тест в качестве примера.

Отделение интерфейса от реализации

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

Когда модульное тестирование не работает

Сложный код

Тестирование программного обеспечения — комбинаторная задача. Например, каждое возможное значение булевской переменной потребует двух тестов: один на вариант TRUE, другой — на вариант FALSE. В результате на каждую строку исходного кода потребуется 3−5 строк тестового кода.

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

Результат известен лишь приблизительно

Например, в математическом моделировании. Бизнес-приложения зачастую работают с конечными и счётными множествами, научные — с континуальными.[1] Поэтому сложно подобрать тесты для каждой из ветвей программы, сложно сказать, верен ли результат, выдерживается ли точность, и т. д. А во многих случаях качество моделирования определяется «на глаз», и последний результат записывается как «опорный». Если найдено расхождение, новый результат проверяют вручную и выясняют, какой качественнее: старый или новый.

Ошибки интеграции и производительности

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

При общей низкой культуре программирования

Для получения выгоды от модульного тестирования требуется строго следовать технологии тестирования на всём протяжении процесса разработки программного обеспечения. Нужно хранить не только записи обо всех проведённых тестах, но и обо всех изменениях исходного кода во всех модулях. С этой целью следует использовать систему контроля версий ПО. Таким образом, если более поздняя версия ПО не проходит тест, который был успешно пройден ранее, будет несложным сверить варианты исходного кода и устранить ошибку. Также необходимо убедиться в неизменном отслеживании и анализе неудачных тестов. Игнорирование этого требования приведёт к лавинообразному увеличению неудачных тестовых результатов.

Проблемы с объектами-заглушками

За исключением простейших случаев, тестируемый объект должен взаимодействовать с другими объектами. Этих «товарищей по взаимодействию» — объекты-заглушки — делают предельно простыми: либо крайне упрощёнными (память вместо БД), либо рассчитанными на конкретный тест и механически повторяющими сессию обмена. Вопросы начинаются, когда протокол обмена меняется; надо отыскивать эти заглушки во всех тестах и переводить под новый протокол.[2]

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

Экстремальное программирование

Экстремальное программирование предполагает как один из постулатов использование инструментов автоматического модульного тестирования. Этот инструментарий может быть создан либо третьей стороной (например, Boost.Test), либо группой разработчиков данного приложения.

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

Техника модульного тестирования

Инструментарий

Для большинства популярных языков программирования высокого уровня существуют инструменты и библиотеки модульного тестирования. Некоторые из них:

  • Для Java и Groovy
    • JUnit [JUnit.org/ JUnit.org]
    • TestNG [testng.org// testNG.org]
    • JavaTESK [www.unitesk.ru/content/category/5/25/60/ UniTESK.ru]
    • [spockframework.org/ Spock] (написан на Groovy)
  • Для C
    • CUnit [cunit.sourceforge.net/ cunit]
    • CTESK [www.unitesk.ru/content/category/5/13/32/ UniTESK.ru]
    • cfix [sourceforge.net/projects/cfix/ cfix]
    • [ispras.linux-foundation.org/index.php/API_Sanity_Autotest API Sanity Autotest] — для динамических C/C++ библиотек в Unix-подобных ОС.
    • Unity [sourceforge.net/projects/unity/ unity] — для встраиваемых приложений
    • MICRO_UNIT [sourceforge.net/projects/microunit/ MICRO_UNIT] — небольшой набор макросов с примерами использования.
  • Для Ruby
    • Rspec [rspec.info/]
    • Test::Unit [www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/index.html]
  • Для Objective-C
    • OCUnit [www.sente.ch/software/ocunit/]
  • Для C++
    • CxxTest [cxxtest.com/cxxtest/doc/guide.html]
    • CPPUnit [apps.sourceforge.net/mediawiki/cppunit/index.php?title=Main_Page]
    • Boost Test [www.boost.org/doc/libs/1_38_0/libs/test/doc/html/index.html]
    • Google C++ Testing Framework [code.google.com/p/googletest/]
    • Symbian[www.symbianosunit.co.uk/] — фреймворк для Symbian OS всех версий.
    • [ispras.linux-foundation.org/index.php/API_Sanity_Autotest API Sanity Autotest] — для динамических C/C++ библиотек в Unix-подобных ОС.
    • [qt.apidoc.info/5.2.0/qttestlib/qttest-index.html Qt Test framework] — для программ, разработанных с помощью библиотеки Qt
  • Для C#
    • Nunit [www.nunit.org/]
    • XUnit.net [xunit.codeplex.com/]
    • MbUnit [www.mbunit.com/]
  • DUnit [dunit.sourceforge.net/] — для Delphi
  • EUnit [svn.process-one.net/contribs/trunk/eunit/doc/overview-summary.html] — Erlang
  • Для Perl
    • Test [search.cpan.org/perldoc?Test]
    • Test::Simple [search.cpan.org/perldoc?Test::Simple]
    • Test::More [search.cpan.org/perldoc?Test::More]
    • Test::Unit [search.cpan.org/perldoc?Test::Unit]
    • Test::Unit::Lite [search.cpan.org/perldoc?Test::Unit::Lite]
  • Для PHP
  • Для Python
    • PyUnit [en.wikipedia.org/wiki/PyUnit]
    • PyTest [codespeak.net/py]
    • Nose [somethingaboutorange.com/mrl/projects/nose/]
  • vbUnit [vbunit.com/] — Visual Basic
  • utPLSQL [utplsql.sourceforge.net/] — PL/SQL
  • Для T-SQL
    • TSQLUnit [sourceforge.net/apps/trac/tsqlunit/]
    • SPUnit [spunit.sourceforge.net/]
  • Для ActionScript 2.0 — язык сценариев, используемый виртуальной машиной Adobe Flash Player версии 7 и 8
    • AsUnit [asunit.sourceforge.net/]
    • AS2Unit [www.as2unit.org/]
  • Для ActionScript 3.0 — скриптовый язык, используемый виртуальной машиной Adobe Flash Player версии 9 и выше
    • FlexUnit [opensource.adobe.com/wiki/display/flexunit/]
    • AsUnit [asunit.org/]
  • Для JavaScript
    • Mocha (тестовый фреймворк) [mochajs.org]
    • Chai («assertion library», используется совместно с тестовым framework’ом) [chaijs.com/]
    • Sinon.JS (библиотека для создания mock’ов, stub’ов, spy’ев, используется совместо с тестовым framework’ом) [sinonjs.org/]
    • Karma runner (от создателей Angular.JS, «test runner» — организует среду выполнения тестов) [karma-runner.github.io/]
    • QUnit (от создателей jQuery) [qunitjs.com/]
    • JsUnit (больше не поддерживается создателями) [www.jsunit.net/]
    • Jasmine (рекомендован создателями jsUnit) [pivotal.github.com/jasmine/]
    • D.O.H [www.dojotoolkit.org/reference-guide/util/doh.html]

Поддержка на уровне языка

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

Пример таких языков:

Пример кода на языке D

class ABC
{
    this() { val = 2; }

    private int val;
    public func() { val *= 2; }
}

unittest
{
   ABC a;
   a.func();

   assert( a.val > 0 && a.val < 555 ); // можно обратиться к приватной переменной внутри модуля
}

Примеры

Java

public class TestAdder {
    public void testSum() {
        Adder adder = new AdderImpl();
        // can it add positive numbers?
        assert(adder.add(1, 1) == 2);
        assert(adder.add(1, 2) == 3);
        assert(adder.add(2, 2) == 4);
        // is zero neutral?
        assert(adder.add(0, 0) == 0);
        // can it add negative numbers?
        assert(adder.add(-1, -2) == -3);
        // can it add a positive and a negative?
        assert(adder.add(-1, 1) == 0);
        // how about larger numbers?
        assert(adder.add(1234, 988) == 2222);
    }
}

Примечания

  1. [habrahabr.ru/post/92038/ Почему юнит-тесты не работают в научных приложениях / Хабрахабр]
  2. [habrahabr.ru/post/275249/ Проблема дублирования и устаревания знания в mock-объектах или Интеграционные тесты — это хорошо / Хабрахабр]

См. также

Ссылки

Сайты и ресурсы
  • [openquality.ru/software-testing/unit-tests.php Тестирование программного обеспечения: модульные тесты] — коллекция статей на сайте OpenQuality.ru  (рус.)
  • [ArtOfUnitTesting.com/ The Art Of Unit Testing]  (англ.)
Статьи
  • [rsdn.ru/article/testing/UnitTesting.xml Модульное тестирование: 2+2 = 4?]  (рус.)
  • [software-testing.ru/library/testing/general-testing/77-2008-09-29-07-30-13 Модульное тестирование. Зачем, как и кто]  (рус.)
  • [weblogs.asp.net/rosherove/archive/2008/01/17/the-evolution-of-unit-testing-and-syntax.aspx The evolution of Unit Testing Syntax and Semantics]  (англ.)
  • [geosoft.no/development/unittesting.html Unit Testing Guidelines from GeoSoft]  (англ.)