Почему качество кода не очень популярно?

Ответ 1

Один очевидный ответ для части Qaru - это не форум. Это база данных вопросов и ответов, а это означает, что попытки дублирования вопросов избегают.

Сколько разных вопросов о качестве кода вы можете себе представить? Вот почему не 50 000 вопросов о "качестве кода".

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

Я также видел более чем достаточно статей о непрерывной интеграции.

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

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

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

Лично я устал от обсуждения "качества кода", потому что они склонны к

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

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

Ответ 2

Обзор кода не является точной наукой. Используемые показатели, используемые как-то спорные. Где-то на этой странице: "Вы не можете контролировать то, что вы не можете измерить"

Предположим, что у вас есть одна огромная функция из 5000 строк с 35 параметрами. Вы можете unit test, сколько вы хотите, он может сделать именно то, что он должен делать. Какими бы ни были входные данные. Поэтому, основываясь на модульном тестировании, эта функция "идеальна". Помимо правильности, есть несколько других атрибутов качества, которые вы, возможно, захотите измерить. Производительность, масштабируемость, ремонтопригодность, удобство использования и т.д. Вы когда-нибудь задумывались, почему программное обеспечение является таким кошмаром?

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

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

• Что нужно измерить?
• Как мы его измеряем?
• Кто будет его измерять?
• Что я получу/потеряю от его измерения?

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

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

РЕДАКТИРОВАТЬ *

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

Ответ 3

• Лень/Считается скучным
• Управление чувствует себя ненужным - Невежественное отношение "Просто сделай это правильно".
• "Этот небольшой проект не нуждается в коде управление качеством "превращается в" Сейчас было бы слишком дорого управление качеством кода на этом большом проект "

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

Calculating vector flow control - PASSED
Assigning flux capacitor variance level - PASSED
Rerouting superconductors for faster dialing sequence - PASSED
Running Firefly hull checks - PASSED
Unit tests complete. 4/4 PASSED.

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

Ответ 4

Почему качество кода настолько непопулярно?

Потому что наша профессия непрофессиональна.

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

Ответ 5

Я думаю, что ответ такой же, как и на вопрос "Почему качество кода не популярно?"

Я считаю, что главными причинами являются:

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

Ответ 6

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

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

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

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

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

Ответ 7

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

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

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

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

Ответ 8

Вероятно, каждый разработчик Java знает JUnit...

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

Я знаю об модульном тестировании и unit test каркасах не менее 7 лет. Я пытался использовать его в небольшом проекте 5-6 лет назад, но только в последние несколько лет я узнал, как сделать это правильно. (т.е. нашел способ, который работает для меня и моей команды...)

Для меня некоторые из этих вещей были:

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

Итак, пока не найдёте правильный путь; да, это скучно, не полезно, трудно сделать, время и т.д.

EDIT: В этом blogpost Я подробно расскажу о некоторых причинах, приведенных здесь для тестирования модулей.

Ответ 9

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

Ответ 10

Качество кода непопулярно? Позвольте мне оспаривать этот факт.

В конференциях, таких как Agile 2009, представлено множество презентаций о непрерывной интеграции, а также методы и инструменты тестирования. Техническая конференция, такая как Devoxx и Jazoon, также имеет свою долю этих предметов. Существует даже целая конференция, посвященная непрерывной интеграции и тестированию (CITCON, которая проводится 3 раза в год на 3 континентах). На самом деле, мое личное чувство заключается в том, что эти разговоры настолько распространены, что они находятся на грани полного скуки для меня.

И по моему опыту в качестве консультанта, консультирование по методам и инструментам качества кода на самом деле довольно легко продать (хотя и не очень высокооплачиваемым).

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

По сути, это сводится к тому, что эти методы все еще достаточно новы (TDD составляет 15 лет, CI менее 10), и им приходится конкурировать с 1) менеджерами, 2) разработчиками, чьи способы "достаточно хорошо работали" до сих пор "(что бы это ни значило). По словам Джеффри Мура, современные методы качества кода все еще находятся на раннем этапе кривой принятия. Это займет время, пока вся индустрия не примет их.

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

Ответ 11

Это довольно просто, когда вы рассматриваете техническую поговорку "Хорошо, быстро, дешево: выберите два". По моему опыту 98% времени, это Быстро и Дешево, и по необходимости другой должен страдать.

Ответ 12

Это напоминает мне об этом Monty Python skit:

"Захватывающий? Нет, нет. Тусклый, тусклый, тусклый. Боже мой, он скучный, он так отчаянно скучный и утомительный, душный и скучный и де-за-съедобный DULL".

Ответ 13

Я бы сказал по многим причинам.

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

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

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

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

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

Ответ 14

"Есть общие предпосылки для того, чтобы не писать тесты, но они только оправдания".

Они? Получите восемь программистов в комнате вместе, задайте им вопрос о том, как лучше всего поддерживать качество кода, и вы получите девять разных ответов в зависимости от их возраста, образования и предпочтений. 1970-е годы "Компьютерные ученые" смеялись над понятием модульного тестирования; Я не уверен, что они ошибались.

Ответ 15

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

Ответ 16

Качество кода субъективно. Субъективные темы всегда утомительны.

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

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

• Это работает? = Бетон.
• Это красиво? = В глазах смотрящего.

Прочитайте Фред Брукс "Мифический Человек Месяц". Нет серебряной пули.

Ответ 17

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

Ответ 18

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

Это похоже на разницу между теорией и применением.

Ответ 19

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

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

Другая причина - нехватка времени. Когда у вас есть задание, где указано "Время завершения: O, 5 человек/дней", у вас есть только время для его реализации и неглубокой проверки, чтобы не думать обо всех возможных случаях и отношениях с другими частями проекта и писать все необходимые тесты. Может потребоваться 0,5 дня, чтобы что-то реализовать, и пару недель, чтобы написать тесты. Если вам специально не дали заказ на создание тестов, никто не поймет эту огромную потерю времени, что приведет к крикам/плохим отзывам. И нет, для нашего сложного корпоративного приложения я не могу придумать хорошее тестовое покрытие для задачи за пять минут. Это потребует времени и, возможно, очень глубокого знания большинства модулей приложений.

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

Ответ 20

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

Был там - видел это.

Ответ 21

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

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

Ответ 22

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

Я нахожу модульное тестирование, чтобы сделать меня более продуктивным, но я видел много плохо отформатированного, нечитаемого плохо разработанного кода, который прошел все его тесты (как правило, длинный код, который был исправлен много раз). Пройдя тесты, вы получите дорогой Skoda, а не мастерство Bristol. Но если у вас есть "низкое качество кода", и вы проходите тесты и последовательно выполняете требования пользователя, то это действительная бизнес-модель.

Мое заключение заключается в том, что разработчики не хотят писать тесты.

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

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

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

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

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

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

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

Ответ 23

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

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

Ответ 24

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

Кроме того, комментарий не близок как "классный", поскольку на самом деле написано пятно кода.

Ответ 25

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

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

Ответ 26

Я не знаю. Вы видели Sonar? Уверен, что это Maven, но укажите его на ваш сбор и бум, множество показателей. Это тот проект, который облегчит выполнение этих показателей качества кода.

Ответ 27

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

Ответ 28

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

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

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

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

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

Ответ 29

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

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

http://agileinaflash.blogspot.com/2010/02/seven-code-virtues.html

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

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

Ответ 30

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

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

кто-то может нарушить ваши тесты и сказать, что он не знает, как исправить или прокомментировать это (если вы используете maven).

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

Вы можете использовать фреймворк, например HtmlUnit, но его очень больно использовать. Селен ломается с каждым изменением на веб-странице. SQL-тестирование почти невозможно (вы можете сделать это с помощью DbUnit, но сначала вам нужно предоставить тестовые данные для него. Данные теста для 5 соединений - это большая работа, и нет простого способа ее генерации). Я не знаю о вашей веб-инфраструктуре, но тот, который мы используем, действительно любит статические методы, поэтому вам действительно нужно работать, чтобы протестировать код.