Стоит ли требовать юнит-тестирование от программистов? [закрыто]

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

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

Я совершенно не в курсе?

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

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

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

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

Лично я считаю, что в вашем случае вы должны думать с точки зрения приемочных испытаний:

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

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

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

Меня удивляет, насколько распространено это мышление. Автоматизировано, да. Модульное тестирование (в одиночку), нет. Автоматизированное тестирование программного обеспечения - это гораздо больше, чем модульные тесты. А как насчет интеграции, системы, функционала, QA? По некоторым причинам люди склонны думать: «Хорошо, поэтому у нас есть правильные юнит-тесты. Закончили с тестированием, назовите это в пятницу вечером!» , Модульное тестирование это только начало.

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

На своей первой работе я работал в том месте, где у нас было 0 юнит-тестов (мы были кучкой юниоров, бросивших более или менее серьезные вещи). Хотите верьте, хотите нет, это сработало. Конечно, никто не был уверен, почему эта ошибка была исправлена ​​или что эта ошибка сломалась, но это сработало. Были времена, когда появлялась какая-то абсолютно случайная ошибка, нобейсбольная бита и риск того, что ваша квартира сгоритнекоторые дополнительные часы могут творить чудеса. Может быть, ваши поставщики используют аналогичные методы ?

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

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

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

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

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

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

Вы даже можете написать тесты или, по крайней мере, спецификации тестов.

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

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

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

Ваша задача состоит в том, чтобы объяснять и убеждать людей - гораздо сложнее навыки!

Сначала я бы начал с руководства, объясняя плюсы и минусы тестирования и отдачи в будущем. Пожалуйста, будьте осторожны, чтобы не выражать эмоции, стоящие за такими утверждениями, как «Я пишу ПРАВИЛЬНЫЕ юнит-тесты» (ваша заглавная) Вы не хотите «кричать» слова (как подразумевает ВСЕ КАПСЫ), вы будете убеждать и убеждать людей, чтобы они сами могли выбрать правильное решение.

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

Принудительное автоматическое тестирование на ком-то не даст желаемых результатов, как отметили @Joachim Sauer и @Telastyn в своих комментариях. Для многих людей автоматизированное модульное тестирование - это огромный сдвиг в их мышлении. Потому что многие люди пишут код, который работает, но не очень тестируем. Я мог бы написать веб-страницу ASP.NET, где вся логика, запросы к базе данных, бизнес-правила, объекты и т. Д. Находятся в коде позади. Будет ли страница работать? Да. Это тестируется с использованием автоматического модульного тестирования? Точно нет. Если у поставщика нет автоматизированного модульного тестирования, ему потребуется немало усилий, чтобы научиться правильно писать модульные тесты и в результате научиться переписывать или перефакторизовывать свой код, чтобы сделать его более легко тестируемым. Скорее всего, они собираются передать эту стоимость на вас.

Дело в том, что поставщик предоставляет вам продукт, будь то DLL или Windows-приложение, и вы ожидаете, что он будет работать в 99% случаев. Конечно, есть ошибки здесь и там, но по большей части это должно работать. Это разумное ожидание, особенно если поставщик хочет сохранить ваш бизнес. Если это черный ящик, то на самом деле не имеет значения, как они заставляют его работать, они могут использовать человеческую волну тестеров или комнату, полную обезьян, случайно нажимающих клавиши. Пока это работает. Но они должны предоставить вам какую-то другую документацию о том, как ее использовать.

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

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

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

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

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

Я нашел эту статью о покупке пользовательского программного обеспечения весьма полезной: http://blog.8thlight.com/paul-pagel/2012/06/20/entrepreneurs-guide-to-buying-software.html

Вопрос номер один, который они рекомендуют задать, - пишет ли поставщик тесты.

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

В процессе проверки ваших поставщиков; спросите их, каков их процесс разработки поскольку тестирование - это только одна часть этого процесса.

Есть ли у них автоматизированный процесс сборки? Они следуют некоторой парадигме управления? Есть ли у них должным образом подготовленные тестеры и независимая команда обеспечения качества? ? Как насчет стандартов документации?

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

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

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

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

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

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

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

Мой совет для вашей ситуации - ищите продавцов, которые предпочитают писать код с помощью модульных тестов, и выбирайте их среди продавцов, которые не пишут код с объединенными тестами. Если руководство заплатит за это, включите в контракт автоматические тесты, но ТОЛЬКО ЕСЛИ ВЕНДЕР ИСПОЛЬЗУЕТСЯ ДЛЯ НАПИСАНИЯ КОДА С ИСПЫТАНИЯМИ БЛОКА.

Давайте сначала определимся с приоритетами ...

В вашей роли клиента ваша главная задача - не юнит-тестирование

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

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

• Каково допустимое количество юнит-тестов?

Должно ли быть 10 тестов? Как насчет 100 тестов? Как насчет 1000 тестов? На самом деле, в начале довольно сложно определить, сколько тестов вам понадобится. Фактическое число на самом деле не определимо ... как проблема остановки ... но мы не решаем эту проблему.

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

• Каков приемлемый уровень покрытия кода?

"100%, конечно!" вы бы подумали. К сожалению, эта метрика вводит в заблуждение; даже если у вас есть 100% покрытие кода, вы действительно уверены, что все работает так, как ожидалось? Возможно иметь 100% покрытие, но этого не сделать.

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

Кроме того, 100% иногда недостижимо при использовании чистых модульных тестов, если у вас есть необходимые взломы производительности и вы используете шаблоны проектирования, которые сложно протестировать (ищите «singleton» и «tdd» в вашей любимой поисковой системе, и вы найдете несколько примеров).

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

Вам потребуется более высокий уровень тестирования

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

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

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

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

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

Итак, когда я, как клиент, смогу заняться модульным тестированием?

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

Откуда вы знаете, что поставщики не пишут юнит-тесты.

Может быть, руководство и продавец провели встречу, и продавец сказал, что код стоит $ X, а модульные тесты - $ Y. Пенни щипала управление, сказала, что мы просто хотим код.

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

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

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

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