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

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

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

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

Воображая все это, стоит ли даже добиваться даже умеренного уровня охвата тестированием? Или вы должны в этом мнимом сценарии просто продолжать делать все возможное с тем, что вам дано и надеяться, молиться или даже жертвовать тем, что клиент согласится переписать на днях, и ТОГДА вы можете начать писать тесты?

ДОПОЛНЕНИЕ

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

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

Ответ 1

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

И, возможно, книга " Эффективная работа с Legacy Code" стоит прочитать?

Изменить

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

Изменить 2

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

Изменить 3

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

Ответ 2

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

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

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

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

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

Ответ 3

Отпустите его

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

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

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

Удачи!

Ответ 4

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

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

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

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

Ответ 5

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

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

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

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

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

Ответ 6

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

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

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

Ответ 7

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

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

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

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

Ответ 8

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

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

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

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

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

Короче

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

Ответ 9

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

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

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

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

Ответ 10

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

Ответ 11

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

Ответ 12

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

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

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

Звучит довольно ужасно. Время на пыль ole возобновить?

Ответ 13

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