вторник, 9 апреля 2013 г.

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

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

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

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

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

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

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

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

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

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

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

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



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

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


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

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



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


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

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

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

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

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

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

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

7 комментариев:

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

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

      Если есть повторяющиеся вещи - далеко не факт, что они написаны правильно и, протестировав одну, не надо тестировать другую. Может быть и наоборот, приходиться тестировать все...

      Удалить
    2. Я с последним абзацем согласна. Но в нем ты говоришь о зависимости UI от Api. А все-таки не про наследование, полиморфизм и т.д.

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

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

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

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

      Я согласна, что это не про полиморфизм уже пошло, просто полиморфизм - это кит, основа :)

      Удалить
  2. А где можно ознакомиться с отчетом о тестировании того сервиса?

    ОтветитьУдалить
    Ответы
    1. Ах да, перекрестные ссылки я еще не делала, сделаю в следующий выпуск, спасибо! Вот отчет - http://okiseleva.blogspot.ru/2013/04/test-it-foodnationru.html

      Удалить