Если модульное тестирование настолько велико, почему больше компаний не делают этого? [закрыто]

Первая настоящая компания-разработчик программного обеспечения, в которой я работал, была посвящена модульному тестированию (NUnit). Я не знаю, были ли мы тогда настоящими сторонниками этого - я понятия не имею, каково было покрытие нашего кода, и я писал большинство модульных тестов. С тех пор я столкнулся с некоторыми компаниями, которые проводят много тестов, но это тестирование на стуле: полагается на присутствие человека, имеет низкую повторяемость и низкую вероятность обнаружения ошибок. Другое отношение: это было то, чем они хотели заниматься «в будущем»; в основном когда деньги падают с неба.

Я скучаю по модульному тестированию - оно просто облегчает жизнь. Но я обнаружил, что, когда я ищу новую работу, модульное тестирование - это либо то, что компании хотели бы «начать» в будущем, либо то, что они вообще не делают (э-э, это уже давно существует сейчас!). Я бы сказал, что 60-75% требований, которые я просматривал за последние 2 года, вообще не включали модульное тестирование. Я могу думать только об одном или двух, которые имели опыт модульного тестирования, как требование (для должности разработчика среднего уровня).

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

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

По моему опыту, это связано с несколькими факторами:

1. Руководство на самом деле не понимает, что такое модульное тестирование на самом деле и почему оно имеет для них реальную ценность.
2. Руководство, как правило, больше заботится о быстрой доставке продукта и (ошибочно) считает, что модульное тестирование контрпродуктивно для достижения этой цели.
3. Существует заблуждение, что тестирование относится исключительно к сфере контроля качества. Разработчики - кодеры и не могут писать тесты.
4. Существует распространенное заблуждение, что руководству придется тратить деньги, чтобы правильно провести модульное тестирование, несмотря на то, что инструменты находятся в свободном доступе. (Конечно, у разработчика есть время, чтобы подумать, но это не слишком много.)
5. Ответ Уилла завершит этот ответ: очень сложно определить значение тестового кода (отредактируйте jcollum)

Естественно, есть и другие факторы, но именно с ними я пока сталкивался.

1) Это сложно
2) Требуется время
3) Очень сложно определить значение тестового кода

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

Легко возложить всю вину на «менеджмент». Но действительно ли руководство говорит вам не проводить модульное тестирование?

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

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

Это просто, когда вы пишете свой собственный строковый класс. Когда вы тестируете реальный продукт, вы сталкиваетесь с проблемами, о которых вам никто не говорил на слайдах PowerPoint:

• Взаимодействие с пользователем. Половина вашего приложения - это логика пользовательского интерфейса. Как вы тестируете его в автоматическом режиме, который не ломается, если вы двигаете кнопку?
• Взаимодействие с внешними API и фреймворками. Если вы пишете драйвер ядра Windows, как вы его тестируете? Вы пишете заглушки для каждой используемой IRP и функции ядра, эффективно создавая симуляцию ядра ОС?
• Сетевые коммуникации - это вещь 21 века. Как вы координируете модульный тест, состоящий из нескольких распределенных компонентов?
• Как выбрать хорошие тестовые примеры? Я часто вижу, как люди пытаются «делать случайные вещи в цикле из 1000 итераций и смотреть, не сломается ли он». Когда вы делаете это, усилия превышают отдачу, важные ошибки упускаются, а модульное тестирование прекращается.
• Как вы проверяете соответствие требованиям к производительности?
• Знания о шаблонах в тестировании скудны: заглушки, стандартные ответы, регрессионное тестирование - понятия, о которых большинство людей не знает. Сколько на вашем рабочем месте на самом деле читают книгу о модульном тестировании?

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

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

Большинство тестов ничего не проверяют.
Вы пишете функцию fileopen () и unittest, которая завершается ошибкой, если файл не существует, и успешной, если файл существует. Большой! Теперь вы проверили, работает ли он с именем файла на китайском языке BIG5? на ресурсе NFS? на Vista с файлом на USB-ключе и включенным UAC?

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

Модульные тесты проверяют ошибки в коде отдельных функций. Они могут работать со слоями доступа к данным, математическими библиотеками и т. Д., Где входы / выходы хорошо известны, а внутренняя структура сложна, но во многих случаях они являются пустой тратой времени.
Они не работают, когда ошибки возникают из-за взаимодействия между различными частями кода или между ОС и пользователем. Такие проблемы, как неправильное отображение настроек высокого / низкого разрешения в диалоговом окне или установка иностранного языка на замену символа '.' и ',' обычно не встречаются.

Были проведены исследования ROI модульных тестов - см. Этот вопрос .

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

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

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

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

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

Что ж, моя компания не пошла на TDD или модульное тестирование. Если честно, мы не знаем, как это сделать. Очевидно, мы можем сделать это для глупых функций вроде CapitalizeString () и т.д., но мы не знаем, как это сделать для очень сложных систем со сложными объектами. Более того, у большинства опрошенных людей либо нулевой, либо ограниченный опыт. Похоже, что модульное тестирование велико из толпы SO, но не особенно велико в доступном рабочем пуле.

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

Короче говоря, мы не верим в TDD, но хотели бы Unit Test. У нас просто нет опыта для этого, и нам нелегко его найти.

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

Воспользуйтесь этим как возможностью заставить их использовать платформу непрерывной интеграции и разработать модульные тесты! Простой способ произвести впечатление на сильных мира сего и одновременно повысить качество и стабильность вашего кода

Изменить: Что касается причины, я думаю, что они просто не знают о текущих инструментах, которые делают CI и модульное тестирование чрезвычайно простым.

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

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

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

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

Я считаю, что это ответ на ваш вопрос «чего не хватает и почему больше компаний не проводят модульное тестирование» . :-)

Вероятно, это комбинация нескольких вещей, о которых вы уже упоминали. Сложно измерить экономию на TDD. Если вы хотите передать свою ИТ-службу на аутсорсинг, вы можете показать, сколько вы платите в год своим сотрудникам по сравнению со стоимостью заключения контракта; это очень конкретно. Как сказать: «О, этот тест обнаружил ошибку, на отладку и исправление которой мне потребовалось бы 4 часа ...»?

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

Кроме того, вы создаете команду (или кого-то), которая должна создать инфраструктуру и поддерживать ее.

И, как говорит Алан , во многих местах просто не используются лучшие практики - они просто хотят увидеть что-то осязаемое.

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

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

Задокументируйте тест в своем коде. Просто оставьте комментарий, объясняющий, где находится тест и как его проводить. Будущие программисты увидят это, и будем надеяться, что тестирование распространится!

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

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

Я большой поклонник модульных тестов, а также являюсь партнером компании, выполняющей проекты контрактной разработки для различных типов клиентов. За месяц мы затронем 3–4 разных проекта разного размера.

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

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

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

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

Я скучаю по модульному тестированию - оно просто облегчает жизнь.

Это не , на самом деле, является достаточным основание для компании принять модульное тестирование.

Достаточной причиной может быть «дешевле» (и / или «лучше»): что не так просто доказать в отношении модульного тестирования.

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

Есть много разработчиков, которые не думают о мире модульных тестов: в том числе те, кто думает, что другие формы тестирования (например, автоматическая интеграция / функциональные тесты) могут быть дешевле и более ценными, например: « Я единственный разработчик, который этого не делает?» как юнит-тесты?

Конечно, в идеальном мире нельзя спорить с модульным тестом.

Однако напишете ли вы модульный тест, зависит от ряда вещей:

• Как будет использоваться программное обеспечение. Если бы вы писали программное обеспечение только для себя, вы бы писали модульные тесты? Возможно нет. Если вы писали готовое программное обеспечение для продажи, возможно, да.

• Сколько людей поддерживают код ... если это только вы, то вы можете знать его достаточно хорошо, чтобы быть достаточно уверенным после внесения изменений, что достаточно быстро просмотреть код, чтобы убедиться, что ничего не сломалось. Если другие люди, которые изначально не писали код, должны теперь поддерживать его, то модульный тест поможет им получить уверенность в том, что при обновлении кода для исправления большого (что, очевидно, не было зафиксировано в модульном тесте!) Они ничего не сломали. .

• сложность кода: только тестовый код, который требует тестирования. Метод присвоения однострочной переменной не требует тестирования. Вероятно, 50-строчный метод с несколькими путями выполнения.

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

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

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

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

Третья причина - лень и / или дешевизна.

Потому что модульные тесты полезны, только если вы пишете тестируемый код. А писать тестируемый код сложно. А люди ленивы и / или дешевы.

РЕДАКТИРОВАТЬ: нюансы «ленивый» как «ленивый и / или дешевый»; в редких случаях люди действительно обладают навыками, способностями и желанием писать тесты, но им есть чем заняться, что напрямую влияет на чистую прибыль.

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

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

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

Люди ленивы и принимают изменения только тогда, когда их заставляют.

Мои 2 цента:

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

Так что это лишь вопрос времени.

Есть дебаты Мартина-Коплиена, в которых Боб Мартин утверждает, что:

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

[ http://www.infoq.com/interviews/coplien-martin-tdd]

Если вы хотите продать всех на тестирование, сделайте следующее:

1. Напишите кучу тестов.
2. Сообщите другим разработчикам, которые изменяют код и не проходят ваш тест (ы).
3. Они исправят свой код.
4. Теперь вы можете выпускать без этих конкретных ошибок.

Это мог понять даже менеджер.

Компании не проводят модульное тестирование по той же причине, по которой многие веб-сайты плохо написаны - незнание и люди, придерживающиеся старых привычек. В моей компании с тех пор, как мы начали модульное тестирование (с Nunit и Typemock ), мы достигли более высокого покрытия кода и выпустили программное обеспечение в более короткие сроки.

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

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

Команда QA вряд ли напишет код модульного теста, потому что компания обычно не укомплектовывает команду QA своими мощными кодировщиками.

Команда программистов не хочет писать тестовый код, потому что это создает конфликт с командой QA.

Я наблюдаю рост интереса к модульному тестированию и его принятие в группах, где QA не выделено в отдельную рабочую функцию.

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

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