Полиморфизм, наследование и прочее в жизни тестировщика

Сидели мы как-то, играли в Шляпу в таком коллективе - я, другая тестировщица и два разработчика. Точнее, одна разработчица, с которой мы и были в паре. А Шляпа - это такая игра, где вы сами придумываете слова, которые будут объяснять участники своей команде. Не называя однокоренных.

И вот мне разработчица и говорит так задумчиво (пытаясь придумать, как объяснить по другому):

- Ну вот в программировании наследование есть...

Я неуверенно откликаюсь:

- Полиморфизм?

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

И даже отчасти был прав, так как моя коллега объяснила его очень просто "та неведомая хрень!"

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

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

Ну раз уж пример сам просится в руки. Дело было вечером, делать было нечего... В общем, прочитав мой отчет в TEST IT про тестирование сайта https://www.foodnation.ru/, мой коллега заинтересовался и мы некоторое время его критиковали. Об этом, наверное, позже, в других выпусках, но посмотрите.

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

Если это один код, еще ладно. А если тестировщик не имеет доступа к белому ящику? Это ведь дополнительная нагрузка, совершенно излишняя, кстати. Но допустим.

Поднимаемся наверх и переключаем на английский язык. Опускаемся к кнопкам и-и-и-и-и... Они по-прежнему русские!

Хм, печально, конечно, но, видимо, у них просто нет локализации для этих кнопок.

А давайте нажмем на эту призывную фразу - "Foodnation in your pocket!". Оп-па... А вот и локализованные кнопки!

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

О чем нам это говорит? О том, что где-то явно идет излишнее дублирование кода.

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

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

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

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

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

Не-е-е-ет, лучше уж вспомнить про китов ООП, Page Object Pattern и прочие премудрости