Стоит ли пытаться писать тесты для самого тесно связанного сайта в мире?

Question

Представьте себе, что 90% вашей работы - это просто сортировка проблем на очень крупном, очень испорченном веб-сайте.Представьте, что этот веб-сайт написан с использованием самого тесно связанного, наименее сплоченного кода PHP, который вы когда-либо видели, - типа кода, который добавит оригинальных разработчиков в ваш список «пощечину».Представьте себе, что это веб-приложение состоит из 4 очень разных частей (1 коммерческая, 2 «перепрофилированных» и 1 пользовательская) и тонны виртуальной клейкой ленты и прокладок.Представьте, что в нем содержатся методы программирования, в которых основные компоненты веб-сайта фактически полагаются на то, что НЕ работает должным образом, а исправление этих поломок обычно приводит к поломке других вещей.Представьте себе, что из слишком большого количества неудачных попыток вы знаете, что изменение одной, казалось бы, безобидной части сайта, такой как разделение поля «имя» на два отдельных поля «первое» и «последнее», поставит сайт на колени и потребует нескольких часовоткаты, слияния и исправления.Представьте, что вы годами просите клиента просто бросить код и начинать все сначала, но его встречают отчаяние корпоративного уровня и выкручивание рук.Затем представьте себе, что вы можете получить билеты как можно скорее для реализации новых функций, которые на любом другом веб-сайте заняли бы 4 часа, но вы лучше разбираетесь в этом сайте, так что вы указываете 40 часов, затем набираете обороты и выставляете счет 80 часов, но это нормально, потому что клиентпривык к этому со своим сайтом.

Вот еще кое-что, что вы также должны себе представить:

• сейчас вообще нет тестов
• естьgoogleteen разных слоев логинов.У некоторых клиентов на самом деле есть 3 разных аккаунта для разных разделов веб-сайта
• , когда я говорю «тесно связанные», я имею в виду, что циклы операторов include / require могут отображаться как кельтский узел
• когда я говорю «наименее сплоченный», я имею в виду, что некоторые вещи организованы вроде MVC, но это не совсем MVC.В некоторых случаях вам может потребоваться несколько часов, чтобы выяснить, как URI A отображается в файл B
• , пользовательский интерфейс был написан как "навязчивый" и "недоступный", были модными словами дня

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

ADDENDUM

Так как многие из вас поднимали этот вопрос: я прибегал к возможности переписывать при каждой возможности, которую мне приходилось встречаться.Специалисты по маркетингу, с которыми я работаю, знают, что их код - дерьмо, и они знают, что это вина фирмы с «самой низкой ставкой», с которой они изначально работали.Я, вероятно, переступил границу подрядчика, указав, что они тратят на меня кучу денег, чтобы обеспечить хосписную помощь для этого участка, и что, перепроектируя его с нуля, они очень быстро увидят ROI.Я также сказал, что я отказываюсь переписать сайт как есть, потому что он на самом деле не делает то, что они хотят, в любом случае.План состоит в том, чтобы переписать его в стиле BDD, но собрать всех ключевых игроков в одном месте непросто, и я все еще не уверен, что они знают, что им нужно.В любом случае, я полностью ожидаю, что это будет очень большой проект.

Спасибо за все отзывы!

Answer 1

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

А может быть, стоит прочитать книгу " Эффективная работа с устаревшим кодом "?

Редактировать

Я бы также порекомендовал посмотреть эту презентацию от Дядя Боб , который затрагивает этот сценарий и как преобразовать базу с плохим кодом в хорошую с помощью «Прогрессивного расширения»

Редактировать 2

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

Редактировать 3

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

Answer 2

Абсолютно нет.

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

Лично я бы сказал, что откажусь от этого и начну все сначала.Четырехчасовые функции, которые занимают 80?Я надеюсь, что это преувеличение.Головные боли у вас должны быть.

Я бы начал с очень твердого предложения переписать кодовую базу.Зажимающие руки клиенты должны иногда говорить тупую правду.Сколько других разработчиков будет работать со сломанной базой?Сделайте несколько симпатичных графиков затрат / выгод.

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

Answer 3

Пройдите тест

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

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

Удачи!

Answer 4

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

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

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

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

Answer 5

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

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

Однако посмотрите на потенциальные выгоды. Это должно сказать вам, действительно ли это того стоит или нет.

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

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

Answer 6

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

Так что вместо того, чтобы указывать 40 часов для исправления, которое должно было занять минуты ... цитата 60. Клиент, похоже, согласен с этим. Используйте 40, чтобы исправить, и 20, чтобы реорганизовать ... и написать тесты для того, что вы реорганизуете. Если 60 бежит до 100, то потратить 120; 80 исправить, а 40 - рефакторинг / тестирование.

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

Answer 7

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

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

Поскольку много кода повторяется (я обнаружил, что один SQL-запрос повторяется 13 раз в одном файле, а во многих других файлах этого проекта - много раз), я могу изменить все остальные места, но я этого не делаю, поскольку они не провереныи при этом я не могу быть уверен, что окружающий код каким-то странным образом не зависит от этого кода (подумайте global).Этот код можно изменить, как только я в любом случае коснусь этого кода.

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

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

Короче

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

Answer 8

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

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

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

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

Answer 9

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

Answer 10

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

Был там, делал это.

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

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