Как убедить спонсора проекта в том, что все функции вашего кода должны иметь модульные тесты

Ответ 1

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

На противоположной стороне, похоже, что крайние сроки проекта не были реалистичными, чтобы фактически построить его.

Ответ 2

Я просто написал подробно об этой самой теме.

Подводя итог моим аргументам против распространенных жалоб:

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

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

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

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

Ответ 3

Попробуйте использовать аналоговый. Спросите их, хотят ли они, чтобы их дети водили автомобили Volvos или Kit, сделанные каким-то парнем по улице. Ответ должен всегда быть Volvo. Тогда спросите почему? Answe ris это более надежный и безопасный. Откуда они знают. Ответ - тестирование. Все автомобили испытываются до предела, и стоимость отражает это. Если они хотят, чтобы программное обеспечение было как можно более надежным, им нужны тесты. (Или они становятся манекенами краш-тестов)

Ответ 4

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

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

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

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

Ответ 5

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

Ответ 6

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

Ответ 7

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

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

Ответ 8

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

Ответ 9

Один хороший способ продать ценность модульных тестов - с точки зрения поддержки - если вы используете модульную систему тестирования, в которой есть среда выполнения, которая может быть развернута (nUnit - один), вы можете получить "Run Unit Tests" "в меню справки. Это может выполнять все модульные тесты, и результаты могут быть отправлены в службу технической поддержки, чтобы помочь отладить проблемы с клиентами.

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