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

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

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

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

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

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

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

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

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

Хотя звучит довольно ужасно. Пора вытирать пыль из старого резюме?

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

И, возможно, стоит прочитать книгу « Эффективная работа с устаревшим кодом »?

Править

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

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

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

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

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

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

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

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

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

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

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

Вкратце

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

Попробуйте

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

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

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

Удачи!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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