Написание "единичного тестируемого" кода?

Какую практику вы используете, чтобы сделать ваш код более дружественным к модулю?

ОТВЕТЫ

Ответ 1

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

  • Рефакторинг для интерфейсов - делает насмешливый легче

  • Публичные методы виртуальные, если не используются интерфейсы - упрощает насмешку

  • Инъекционная инъекция - делает насмешкой проще

  • Меньшие, более целенаправленные методы - тесты более сфокусированы, написать

  • Избегание статических классов

  • Избегайте одиночных игр, кроме случаев, когда необходимо

  • Избегайте закрытых классов

Ответ 2

Похоже, что инъекция зависимостей помогает.

Ответ 3

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

Ответ 4

  • Использовать TDD
  • При написании кода используйте, когда это возможно, инъекцию зависимостей
  • Программа для интерфейсов, а не для конкретных классов, поэтому вы можете заменить макетные реализации.

Ответ 5

Убедитесь, что все ваши классы следуют Принцип единой ответственности. Единая ответственность означает, что каждый класс должен иметь одну и только одну ответственность. Это значительно упрощает модульное тестирование.

Ответ 6

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

Ответ 7

Самый простой способ - не проверять код, если вы не проверяете его.

Я не большой поклонник написания тестов в первую очередь. Но я считаю, что очень важно, что код должен быть проверен в с тегами. Даже не раньше часа, togther. Я думаю, что порядок, в котором они написаны, менее важен, пока они входят вместе.

Ответ 8

Небольшие, высокосвязные методы. Я изучаю это с трудом. Представьте, что у вас есть общедоступный метод, который обрабатывает аутентификацию. Возможно, вы сделали TDD, но если метод большой, его будет сложно отладить. Вместо этого, если этот метод #authenticate делает материал более псевдо-codish способом, вызывая другие мелкие методы (возможно, защищенные), когда появляется ошибка, легко написать новые тесты для этих небольших методов и найти неисправный.

Ответ 9

И что-то, что вы узнаете первым в ООП, но так много, кажется, забывают: Code Against Interfaces, Not Implementations.

Ответ 10

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

Ответ 12

Я уверен, что я за него проголосовал, но я все равно выскажу свое мнение:)

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

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

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

Ответ 13

Я использую Test-Driven Development, когда это возможно, поэтому у меня нет кода, который не может быть проверен модулем. Он не существовал бы, если бы существовал unit test.

Ответ 14

1.Using a framework/pattern like MVC to separate your UI from you
business logic will help a lot. 
2. Use dependency injection so you can create mock test objects.
3. Use interfaces.

Ответ 15

Проверьте этот разговор Автоматизированные шаблоны тестирования и запахи. Одна из главных причин для меня заключалась в том, чтобы убедиться, что код UnitTest имеет высокое качество. Если код хорошо документирован и хорошо написан, все будут мотивированы, чтобы сохранить это.

Ответ 16

Чтобы подготовить свой код к тестированию:

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

Чтобы получить максимальную отдачу от своих модульных тестов, рассмотрите следующее:

  • Просветите себя и свою команду разработчиков о возможностях модульной системы тестирования, насмешливых библиотеках и инструментах тестирования, которые вы собираетесь использовать. Понимание того, что они могут и чего не могут сделать, будет существенно, когда вы начнете писать свои тесты.
  • Расставьте свои тесты, прежде чем начинать их писать. Определите случаи кросс, ограничения, предварительные условия, постусловия и исключения, которые вы хотите включить в свои тесты.
  • Исправьте неисправные тесты как можно ближе к тому, когда вы обнаружите их как можно более. Тесты помогут вам выявить недостатки и потенциальные проблемы в вашем коде. Если ваши тесты сломаны, вы откроете дверь, чтобы впоследствии исправить больше вещей.
  • Если вы следуете процессу проверки кода в своей команде, код также проверяет ваши модульные тесты. Единичные тесты являются такой же частью вашей системы, как и любой другой код - обзоры помогают выявлять недостатки в тестах так же, как и для системного кода.

Ответ 17

Нет статистики - вы не можете издеваться над статикой.

Также у Google есть инструмент, который будет измерять тестируемость вашего кода...

Ответ 18

Я постоянно пытаюсь найти процесс, в котором модульное тестирование - это не просто работа, а то, что я действительно ХОЧУ сделать. По моему опыту, довольно большой фактор - это ваши инструменты. Я много работаю над ActionScript и, к сожалению, инструменты несколько ограничены, например, нет интеграции IDE и отсутствия более продвинутых фальсифицированных фреймворков (но хорошие вещи идут, поэтому никаких претензий здесь нет!). Я уже делал тест-драйв разработки с более зрелыми платформами тестирования, и это было, безусловно, более приятным опытом, но все-таки казалось, что это была небольшая работа.

Недавно я начал писать код по-другому. Раньше я начинал с написания теста, наблюдая, как они терпят неудачу, записывая код, чтобы сделать тест успешным, полоскать и повторить, и все такое.

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

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

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

О, я также хотел добавить, что я не пишу тесты на все. Свойства Vanilla, которые не делают ничего, кроме переменных get/set, бесполезны для тестирования. Они работают по языковому контракту. Если у них нет, у меня проблемы с худшими, чем у моих юнитов, которые не проверяются.

Ответ 19

Вам необязательно "делать код более дружественным к модулю".

Вместо этого инструмент для издевательств может использоваться для устранения проблем с тестируемостью. Одним из таких инструментов является JMockit.