Что такое tdd в тестировании

Деконструкция TDD

Здравствуйте, меня зовут Дмитрий Карловский. А вы на канале Core Dump, где мы берём разные темы из компьютерной науки и деконструируем их по полочкам. Начнём мы с разработки через тестирование.

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

Этот ритуал сделает ваш код красивым и надёжным. Поддерживать его будет легко и просто. А разработка будет простой и быстрой. Так во всяком случае настоятельно убеждают нас проповедники TDD.

Суть TDD

Вкратце, ритуальный цикл состоит из 3 шагов: сначала пишется красный тест; потом пишется или исправляется код так, чтобы тест позеленел; и наконец код рефакторится, сохраняя зеленоватость тестов.

И тут сразу возникает вопрос вопрос на миллион.

Что делать, когда тест изначально зелёный?

Если сломать код, то тесты естественным образом покраснеют. А после того как мы откатим изменение, тесты снова станут зелёными.

Можно удалить тест. Ведь если нет теста, то нет и проблемы с его изначальным цветом.

Наконец, моё любимое: по TDD такого быть не должно. Где-то ты накосячил, что у тебя так получилось. Покайся, грешник.

А теперь, внимание, правильный ответ: все эти варианты — это полная беспросветная чушь. Хотя именно один из них, как правило, слышишь от адептов TDD.

Парадокс воронов

Говоря про ломание кода, нельзя не упомянуть про парадокс воронов. Суть его в том, что задаётся вопрос: «Все ли вороны чёрные?». И для ответа на него берутся нечёрные предметы. Например — красные яблоки. И каждое такое яблоко как бы подтверждает тезис о том, что «все вороны чёрные», ведь яблоки не чёрные и при этом не вороны. Что-то тут не так с логикой, не правда ли?

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

Поломка и починка кода — это не более чем бессмысленное действие, необходимое только для того, чтобы формально пройти 2 обязательных шага ритуального цикла. Но насколько вероятна эта зелёная ситуация?

Изначально зелёные тесты неизбежны

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

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

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

Правильный TDD

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

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

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

И, наконец, обратите внимание, что даже после рефакторинга мы задаёмся вопросом «А нужен ли ещё один тест?». Но как же так, — спросите вы, — мы же уже покрыли все тест-кейсы. Причина тут в том, что рефакторинг может приводить к существенному изменению кода. А это в свою очередь может изменить граничные условия, для учёта которых могут потребоваться дополнительные тесты.

В такой форме TDD уже можно применять с пользой. Однако.

TDD приводит к куче лишней работы

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

Давайте рассмотрим типичный сценарий написания простой функции.

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

Но всё не так плохо, с какого-то момента мы перестанем выбрасывать код полностью, и добавление нового теста уже не будет приводить нас к существенному переписыванию кода. То есть цикл TDD наконец-то начнёт работать как задумывался.

Однако, всё ещё остаётся довольно высокая вероятность в любой момент столкнуться с такой ситуацией, что очередное изменение кода сломает вообще все тесты. Ну или как минимум большую их часть. А значит мы снова возвращаемся к ситуации «все тесты уже написаны, нужно лишь написать правильно код». А все те осторожные шажки по одному тесту, что мы делали ранее, просто обесцениваются.

Когда TDD полезен

Как было отмечено ранее применение TDD в общем случае скорее вредно, чем полезно. Но в некоторых случаях оно может быть оправдано..

Если к вам пришёл баг, то вы его можете сперва формализовать в виде теста, а далее исправлять код, пока все тесты не позеленеют.

Кроме того, в ситуации, когда контракт вам известен заранее, вы можете сразу написать все тесты, а потом уже весь код, который им соответствует. Формально, это будет не TDD, так как вы не будете менять код после добавления каждого теста. Однако, это самый что ни на есть Test Driven, так как тесты будут диктовать вам реализацию.

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

Программировать ли по TDD?

Если кто-то вам скажет, что он «программирует по TDD», то можете быть уверены, что он попросту не ведает, что творит. У TDD есть ряд фундаментальных проблем, поэтому его применение оправдано лишь в весьма ограниченном числе случаев. И то, не в той форме в которой ему как правило учат многочисленные коучи.

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

Что ещё посмотреть по TDD?

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

Продолжение следует..

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

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

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

Наконец, подписывайтесь на канал, чтобы не пропустить дальнейшие разборы. Нам ещё много чего с вами нужно будет обсудить.

Источник

TDD: Что пошло не так?

Эта статья является переводом материала «TDD: What went wrong or did it?».

В сфере разработки программного обеспечения уже давно хвалят Test Driven Development (TDD, разработка через тестирование). Однако в последнее время было сказано много резких слов в адрес TDD, поскольку его обвиняют в плохом проектировании программного обеспечения и невыполнении многих своих обещаний. Кульминацией этой тенденции стал пост Дэвида Хайнемайера Ханссона «TDD is dead. Long live testing.» (TDD мертв. Да здравствует тестирование).

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

Начнем с самого тонкого и самого деструктивного.

TDD это не «Проектирование через тестирование»

TDD расшифровывается как “Разработка через тестирование”. К сожалению, многие неверно истолковывают это как “Проектирование, основанное на тестировании”. Эта неточность может показаться невинной, но поверьте мне, это не так. Позвольте мне объяснить.

Если вы разрабатываете в первую очередь для тестируемости, вы получаете то, за что платите, — тестируемый код. Чаще всего этот дизайн будет полностью не связан с бизнес-областью и требованиями проекта. Он будет напоминать огромный граф объектов, полный случайных сложностей. но он будет проверяемым. Тестируемый тестами, которые тонут в моках (имеется в виду mock как тестовый двойник), и полностью сломается после изменения одного кусочка в реализации. Это то, что называется “повреждением, вызванным тестом”, и это ярко показано в блоге Дэвида Хайнемайера Ханссона «TDD is dead. Long live testing.»:

Нынешний фанатичный опыт TDD приводит к тому, что основное внимание уделяется модульным тестам, потому что это тесты, способные управлять дизайном кода (первоначальное обоснование для test-first – сначала тестирование, потом реализация). Я не думаю, что это здорово. Test-first приводят к чрезмерно сложной сети промежуточных объектов и косвенных обращений, чтобы избежать «медленных» действий. Например, попасть в базу данных. Или файл IO. Или пройти через браузер, чтобы протестировать всю систему. Это породило некоторые поистине ужасные архитектурные уродства. Густые джунгли служебных объектов, командных шаблонов и прочего.

TDD это не (только) о модульных тестах

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

Вы имеете дело со сложной бизнес-логикой? Вам действительно нужны модульные тесты здесь.

Вы выполняете только простые операции CRUD? Используйте интеграционные тесты или сквозные тесты.

Сценарий ETL? Достаточно сквозных тестов.

. И, говоря о модульных тестах, что вообще такое модуль? Переходим к третьему заблуждению.

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

Определение модуля, которое мне нравится больше всего, принадлежит Рою Ошерову, автору книги The Art of Unit Testing:

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

Отсутствие буквы D в TDD

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

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

P.S TDD 2.0

TDD был «заново открыт» Кентом Беком более десяти лет назад. Возможно, пора снова открыть TDD. Помимо модульных тестов, новая спецификация должна касаться других типов автоматизированных тестов, которые в то время были недоступны. И, конечно же, вместо того, чтобы работать против, TDD должен тесно сотрудничать с бизнес-областью.

Источник

Что такое TDD (test-driven development)

TDD существует с 1999 года и является методом разработки программного обеспечения, основанном на тестировании. В 2003 году американский разработчик Кент Бек «заново открыл» TDD и применил его как способ создания простых конструкций и внушающих доверие. На сегодняшний день, TDD – это процесс разработки программного обеспечения, использующий очень короткий цикл обратной связи, при котором разработчики:

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

Оглавление

Развитие TDD

Подход TDD отличается от других методов тем, что он объединяет программирование с написанием тестов самим разработчиком. Эта концепция возобновляет всеобщее уважение к тестам, созданным программистом.

1976 год. Публикация Гленфорда Майерса «Надежность программного обеспечения», которая определяет, как аксиому то, что программист никогда не должен тестировать свой собственный код (Dark Age of Developer Testing).

1990 год. В дисциплине тестирования преобладают методы «черного ящика», в частности, в форме инструментов тестирования «поймай и повтори».

1991 год. Независимое создание тестовой среды в Taligent поразительно похожей на SUnit.

1994 год. Кент Бек пишет тестовый скелет SUnit для Smalltalk.

1998 год. Статья об экстремальном программировании упоминает, что «мы обычно пишем тест в первую очередь».

С 1998 по 2002 год. Test First преобразован в Test Driven.

2000. Автоматизированные тесты – инновационные методы, разработанные в этот период.

2003 год. Публикация Кента Бека «Разработка через тестирование: на примере».

В 2006 году TDD превратился в признанную технику, которая стала поощрять дальнейшие инновации, такие как разработка на основе приемочных испытаний (ATDD) и развитие на основе поведения (BDD).

Что же такое Test Driven Development (TDD)?

Разработка через тестирование – это подход к программированию, при котором программирование должно вестись на основании тестирования, а не наоборот. При традиционном подходе к разработке программного обеспечения заказчик выдвигает требования к программе. Затем разработчик создает код, который соответствует критериям приемлемости пользовательской истории. Затем код будет объединен и протестирован тестировщиком в среде QA или SIT. Тестер может найти дефекты. В этом случае код отправляется на доработку.

Существует цикл: написать код, запустить тесты, исправить код. Test Driven Development переворачивает этот цикл с ног на голову. В нем говорится, что мы должны сначала создать тесты, затем написать код, после чего исправить код.

В Test Driven Development сначала пишется и запускается тест, затем пишется код (до тех пор, пока он не пройдёт тест), а затем код реорганизуется. Это называется рефакторинг.

Рефакторинг

Целью рефакторинга является чистый код, который идеально работает. Рефакторинг – это модификация исходного кода системы после незначительных изолированных изменений, не приводящих к изменению функциональности.

Функциональность может быть проверена во время рефакторинга путем многократного запуска тестов.

Рефакторинг может значительно улучшить читаемость кода, устранить дублирование, облегчить техническое обслуживание и расширение системы в будущем. Поскольку это небольшие, определенные и контролируемые изменения, их также можно автоматизировать с помощью инструментов рефакторинга, которые уже интегрированы во многие популярные среды разработки, что значительно повышает производительность труда разработчиков. Основной каталог модификаций – рефакторинг можно найти в отличной книге Мартина Фаулера «Рефакторинг».

Красный, зеленый, рефакторинг

Принцип работы в программировании TDD суммирует Кент Бек в хорошо запоминающийся фразу: красный, зеленый, рефакторинг. Названия цветов относятся к пользовательскому интерфейсу популярного автоматического запуска теста JUnit, где красная полоса указывает на то, что тест не пройден, а зеленая полоса указывает на то, что тест прошел успешно.

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

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

Кент Бек, в eXtreme Programming (XP) (Beck 2000), определяет два простых правила для TDD:

Бек объясняет, как эти два простых правила генерируют сложное индивидуальное и групповое поведение:

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

Какие существуют виды тестов?

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

Модульные тесты – тестирование приложения изнутри, с точки зрения программиста. Они тестируют код, выполняя тесты, проверяющие правильность работы библиотечных объектов / модулей / систем.

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

Эти типы тестов образуют Тестовую пирамиду.

Считается, что большинство тестов должны быть модульными, с меньшим количеством интеграционных тестов и ещё меньшим приемочных тестов. Google рекомендует соотношение примерно 70/20/10.

Инструменты

TDD должен сочетаться с хорошими инструментами. Необходима среда IDE, такая, как Eclipse с собственной поддержкой JUnit. Настоятельно рекомендуется использовать плагины для облегчения управления модульными тестами, такими как MoreUnit и Infinitest. Последний автоматически выполняет все модульные тесты при каждом изменении кода, что уменьшает циклы обратной связи, которые также закладывают основы для непрерывных модульных тестов. С другой стороны, использование шаблонов кода для модульных тестов является важной экономией времени в повторяющемся цикле TDD. На уровне кода для создания удобочитаемых и гибких бизнес-объектов необходим шаблон проектирования Builder.

Платформы и инструменты для тестов TDD для проектов PHP

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

Behat – это фреймворк BDD PHP с открытым исходным кодом, который использует «человеческие» предложения для запуска тестов программного обеспечения. Behat инструмент предложенный StoryBDD. Помогает определить описательные части, их потребности и вложенный в них смысл. Behat предлагает уникальный подход к тестированию.

Codeception – еще один надежный инструмент TDD для PHP. Codeception похож на PHPUnit и Behat, но все его тесты написаны на PHP, что делает процесс разработки более гибким. Во всех тестах Codeception можно использовать переменные и операторы, а также локаторы CSS и XPath.

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

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

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

Сокращает общее время разработки: практика показывает, что уменьшается общее время разработки проекта по сравнению с традиционными методами написания кода. В то время как общее количество строк кода увеличивается (из-за тестов), частое тестирование исключает ошибки в процессе и выявляет существующие намного раньше, предотвращая возникновение проблем в дальнейшем.

Недостатки тест-ориентированной разработки

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

Не подходит для всех: метод отлично зарекомендовал себя для работы с небольшими проектами или даже с небольшими компонентами или функциями крупных проектов. К сожалению, методика может давать сбои при применении к очень объёмным или сложным проектам. Написание тестов для сложной функции, которую программист ещё полностью не представляет, может быть трудным, и даже невозможным. Написание тестов – это хорошо, но если эти новые тесты не совсем точно соответствуют требованиям функции, они бесполезны (или даже могут активно препятствовать разработке). Более того, некоторые проекты, особенно те, которые используют устаревший код или сторонние системы, просто не поддаются практическим методам. Для них практически невозможно создать тесты, которые должным образом интегрируются с этими системами или с устаревшим кодом.

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

Когда применяется TDD

TDD подходит как для нового программного обеспечения, так и для устаревших систем. Для команды разработчиков, которая имеет дело с существующим устаревшим программным обеспечением, работа начинается исправлением ошибок. Хорошей практикой является то, что для каждой сообщаемой ошибки создаётся тест, который устраняет ошибку, а затем исправляется функциональность. После нескольких итераций команда разработчиков создаёт повторяемый рабочий тест для исправления ошибок. Применяя эту методологию к новым программным приложениям, следует обратить внимание на инструменты тестирования, используемые для стека технологий. Например, при работе в приложении Angular, которое обычно использует среду тестирования Jasmine для модульного тестирования, и при использовании для Angular CLI, модульные тесты создаются вместе с модулями кода. Методология TDD будет заключаться в следующем:

Измерение тестируемости с помощью покрытия кода

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

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

Практика использования TDD

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

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

Резюме

Разработка через тестирование – это метод, который в настоящее время широко используется и становится все более популярным. Причина его популярности заключается в том, что усилия, необходимые для его освоения, не так велики, как для экстремального программирования, частью которого является TDD. Хотя у разработчика с самого начала должна быть дисциплина для написания и запуска тестов, без него не было бы программирования, управляемого тестами. Из-за своей природы метод может использоваться в сочетании с различными практиками разработки на более низком уровне (например, в течение одной итерации) и даже в более широком спектре проектов.

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

Источник