Как делают меня действительно код модульного теста?

Не зацикливайтесь на подсчете строк кода. Напишите столько тестового кода, сколько вам нужно, чтобы убедиться, что каждый ключевой элемент функциональности тщательно тестируется. В качестве крайнего примера, в проекте SQLite соотношение тестов: исходный код больше 600: 1 . Здесь я использую термин «крайний» в хорошем смысле; смехотворное количество тестов, которые продолжаются, возможно, является преобладающей причиной того, что SQLite захватил мир.

Вот что я слышу, имели ли вы это в виду или нет: целый ряд проблем и оправданий, почему модульное тестирование может быть неприменимо к вашему коду. Другими словами: «Я не понимаю, что я получу от модульных тестов, и их очень сложно написать; может быть, они не для меня?»

Знаете что? Вы можете быть правы. Модульные тесты - не панацея. Есть огромные и обширные области тестирования, которые не могут быть покрыты модульным тестированием.

Я думаю, однако, что вы неправильно оцениваете стоимость обслуживания и то, что может сломаться в вашем коде. Итак, вот мои мысли:

• Следует ли мне тестировать небольшие классы? Да, если в этом классе есть вещи, которые могут сломаться.
• Следует ли мне тестировать функции? Да, если в этой функции есть что-то, что может сломаться. Почему бы и нет? Или вас беспокоит, считается ли это единицей или нет? Это просто придирки по поводу имен, и это не должно иметь никакого отношения к тому, стоит ли вам писать для этого модульные тесты! Но по моему опыту часто можно увидеть метод или функцию, описываемую как тестируемый модуль.
• Должен ли я проводить модульное тестирование класса, если он используется двумя другими классами? Да, если что-то может сломаться в этом классе. Должен ли я тестировать его отдельно? Преимущество этого заключается в том, чтобы иметь возможность изолировать поломки прямо до общего класса, вместо того, чтобы искать среди используемых классов, чтобы узнать, сломались ли они или один из них зависимости.
• Должен ли я тестировать вывод данных моего класса, если его прочитает другая программа? Черт возьми, , особенно если эта другая программа является сторонней! Это отличное применение модульных тестов (или, возможно, системных тестов, в зависимости от изоляции, задействованной в тесте): чтобы доказать себе, что выводимые вами данные - это именно то, что, по вашему мнению, вы должны выводить. Я думаю, вы обнаружите, что это может неизмеримо упростить обращение в службу поддержки. (Хотя, пожалуйста, обратите внимание, что это не заменяет хорошего приемочного тестирования на стороне клиента.)
• Следует ли мне тестировать одноразовый код? Возможно. Сможет ли стратегия TDD быстрее избавить вас от ненужного кода? Может. Сможет ли наличие надежных блоков, протестированных на единицу продукции, которые вы можете адаптировать к новым ограничениям, уменьшить необходимость выбрасывать код? Возможно.
• Следует ли мне тестировать код, который постоянно меняется? Да. Просто убедитесь, что все применимые тесты обновлены и проходят! В конце концов, постоянно меняющийся код может быть особенно подвержен ошибкам, а возможность безопасного изменения - еще одно большое преимущество модульного тестирования. Кроме того, это, вероятно, заставляет ваш инвариантный код быть как можно более надежным, чтобы обеспечить такую ​​скорость изменения. И вы знаете, как убедиться в надежности кода ...
• Следует ли мне тестировать функции, которые больше не нужны? Нет, вы можете удалить тест и, возможно, код (конечно же, тестирование, чтобы убедиться, что вы ничего не сломали!). Не оставляйте модульный тест бесполезным, особенно если тест больше не работает или не запускается, или люди в вашей организации откажутся от модульных тестов, и вы потеряете все преимущества. Я видел, как это происходило. Это некрасиво.
• Следует ли мне тестировать код, который не используется в моем проекте, даже если он был написан в контексте моего проекта? Зависит от конечных результатов вашего проекта и каковы приоритеты вашего проекта . Но уверены ли вы, что никто за пределами вашего проекта им не воспользуется? Если они этого не сделают, а вы нет, возможно, это просто мертвый код, в этом случае см. Выше. С моей точки зрения, я бы не почувствовал, что выполнил всю работу с классом, если бы мое тестирование не охватывало все его важные функции, независимо от того, использовал ли проект все эти функции или нет. Мне нравятся уроки, которые кажутся законченными, но я стараюсь не переусердствовать с кучей ненужных мне вещей. Если я помещаю что-то в класс, я предполагаю, что это будет использоваться, и поэтому хочу убедиться, что это работает. Для меня это вопрос личного качества и удовлетворения.

Относительное количество LOC для кода и тестов бессмысленно. Что имеет большее значение, так это покрытие тестами. Самое главное - найти ошибки.

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

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

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

Я не считаю это проблемой. Для меня интересно то, что написание тестов меня не тормозит. Скорее это заставляет меня сосредоточиться на коде, когда я его пишу.

Так что да, протестируйте все. Старайтесь не думать о тестировании как о рутине.

Как вы можете проделать все эти вычисления? В идеале вы никогда не должны оказаться в ситуации, когда вы можете подсчитать строки вашего завершенного класса, а затем начать писать модульный тест с нуля. Эти 2 типа кода (реальный код и тестовый код) должны разрабатываться и развиваться вместе, и единственная метрика LOC, которая действительно должна вас беспокоить, - это 0 LOC для тестового кода.

Некоторое время назад у меня был тот же вопрос, который вы задали в уме. Я изучил много статей, руководств, книг и так далее ... Хотя эти ресурсы дают мне хорошую отправную точку, я все еще не был уверен в том, как эффективно применять код модульного тестирования. После того, как я наткнулся на xUnit Test Patterns: Refactoring Test Code и положил его на полку примерно на год (вы знаете, у нас есть много вещей для изучения), он дает мне то, что мне нужно для эффективного применения Unit Код тестирования. Имея множество полезных шаблонов (и советов), вы увидите, как стать кодировщиком модульного тестирования. Темы как

• Шаблоны стратегии тестирования
• Базовые шаблоны
• Шаблоны настройки устройств
• Шаблоны проверки результатов
• Тестовые двойные шаблоны
• Тестовые шаблоны организации
• Шаблоны базы данных
• Шаблоны значений

И так далее ...

Я покажу вам, например, шаблон производного значения

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

Шаблон организации тестирования, связанный с вашим вопросом (класс Testcase для каждой функции )

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

Но перед чтением

_{(источник: xunitpatterns.com )}

Мой совет: внимательно прочтите

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

Во-вторых, какие классы вам следует тестировать? Опять же, TDD (или, точнее, некоторые принципы, лежащие в его основе) может помочь. Если вы разрабатываете свою систему сверху вниз и сначала напишете свои тесты, у вас будут тесты для внешнего класса при написании внутреннего класса. Эти тесты должны завершиться неудачно, если во внутреннем классе есть ошибки.

TDD также тесно связан с идеей Design for Testability .

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

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

Поскольку мы живем в реальном мире, у нас нет времени добавлять тестовый код для всех существующих функций. У нас все еще есть Дэйв, тестирующий, который находит большинство ошибок. Вместо этого по мере развития мы пишем тесты. Вы знаете, как запустить свой код, прежде чем сказать своему боссу, что он работает? Что ж, используйте модульную структуру (мы используем Junit) для выполнения этих прогонов. И просто сохраните их все, а не удаляйте. Все, что вы обычно делаете, чтобы убедить себя, что это работает. Сделай это.

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

для java можно использовать junit

JUnit

JUnit - это простой фреймворк для написания повторяемых тестов. Он является частью архитектуры xUnit для фреймворков модульного тестирования.

* Getting Started
* Documentation
* JUnit related sites/projects
* Mailing Lists
* Get Involved

Начало работы Чтобы начать работу с модульным тестированием и JUnit, прочитайте статью: JUnit Cookbook. В этой статье описываются основы написания тестов с использованием JUnit 4.

Дополнительные примеры вы найдете в пакете org.junit.samples:

* SimpleTest.java - some simple test cases
* VectorTest.java - test cases for java.util.Vector

JUnit 4.x поставляется только с текстовым TestRunner. Для графического представления большинство основных IDE поддерживают JUnit 4. При необходимости вы можете запускать тесты JUnit 4 в среде JUnit 3, добавив следующий метод в каждый класс теста:

public static Test suite() { return new JUnit4TestAdapter(ThisClass.class); }

Документация

JUnit Cookbook
    A cookbook for implementing tests with JUnit.
Javadoc
    API documentation generated with javadoc.
Frequently asked questions
    Some frequently asked questions about using JUnit.
Release notes
    Latest JUnit release notes
License
    The terms of the common public license used for JUnit.

Следующие документы по-прежнему описывают JUnit 3.8.

The JUnit 3.8 version of this homepage
Test Infected - Programmers Love Writing Tests
    An article demonstrating the development process with JUnit.
JUnit - A cooks tour 

Проекты/сайты, связанные с JUnit

* junit.org - a site for software developers using JUnit. It provides instructions for how to integrate JUnit with development tools like JBuilder and VisualAge/Java. As well as articles about and extensions to JUnit.
* XProgramming.com - various implementations of the xUnit testing framework architecture. 

Списки рассылки Существует три списка рассылки junit:

* JUnit announce: junit-announce@lists.sourceforge.net Archives/Subscribe/Unsubscribe
* JUnit users list: junit@yahoogroups.com Archives/Subscribe/Unsubscribe
* JUnit developer list: junit-devel@lists.sourceforge.net Archives/Subscribe/Unsubscribe

Get Involved JUnit - это праздник программистов, тестирующих свое собственное программное обеспечение. В результате ошибки, исправления и запросы на функциональность, включающие JUnit TestCases, имеют больше шансов быть рассмотренными, чем те, которые без них. Исходный код JUnit теперь размещен на GitHub.

Одна из возможностей - сократить «тестовый код» до языка, который описывает ваши тесты, и интерпретатора для запуска тестов. Команды, в которых я входил, использовали это в прекрасных целях, что позволило нам написать значительно больше тестов, чем можно было бы указать в «строках кода».

Это позволило намного быстрее писать наши тесты и значительно повысили удобочитаемость тестов.

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

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

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

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

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

Для меня это кажется здравым смыслом.