/ web

Front-end ремесло

Перевод статьи Craft the Front-end

Как мне это реализовать? Это нормальная практика?

Если вы когда-нибудь задавали себе такие вопросы, эта статья (и следующие 🤗), наполненная примерами из реальной жизни, наверняка даст вам ответы на некоторые из них!

Статья состоит из трех разделов:

  • Адаптивный дизайн (CSS, TypeScript и Jest),
  • Объектно-ориентированная SCSS,
  • Расширенное тестирование в Jest.

Наслаждайтесь чтением!

Адаптивный дизайн

Допустим, вы пишете приложение с различным дизайном для настольных и мобильных устройств. Некоторый контент отображается только для экранов размера меньше, чем 1024px. Когда вы проверяете это вручную, похоже, все работает отлично. Но было бы круто протестировать это, не так ли? 😉

Вы пишете тесты для desktop, и они зеленые! Да, конечно, это вы написали код, а они просто тестируют какую-то глупую функциональность. Но как проверить мобильную часть?

Предположим, что тесты написаны на Jest. Вы проверяете документацию и видите, что Jest по умолчанию устанавливает ширину экрана 1024px. Хм, а как изменить размер экрана для тестирования?

К счастью, это возможно - посмотрите пример на TypeScript ниже:

Если вы не знакомы с адаптивным дизайном, вам может быть интересно, как можно показать разные вещи для экрана разных размеров экрана. Есть два способа сделать это:

  • код,
  • CSS (или даже лучше: SCSS).

Давайте рассмотрим последний вариант  @media(max-width: _px) { ... } . Вы можете задаться вопросом:
Не станет ли файл CSS менее читаемым из-за разбросанных по нему медиа-тегов?

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

Вам понравились файлы SASS выше? Могу поспорить, что да, но зацените следующий раздел! 🤩

Объектно-ориентированный CSS

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

Посмотрите, как мы сохранили DRY (DONT REPEAT YOURSELF) код с наследованием и композицией! Кто сказал, что CSS (на самом деле SCSS) не может быть объектно-ориентированным ?!

Расширенное тестирование

Мы начали с тестирования, поэтому давайте закончим так же!

2

Иногда ожидается, что код выдаст исключение, если что-то пойдет не так. Но как проверить, что такая ошибка действительно была выброшена? На самом деле, есть несколько способов сделать это. Давайте рассмотрим два из них:

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

Во втором мы прекрасно используем функцию из Jest. Существует только одно предупреждение - убедитесь, что вы вызываете функцию в части expect! В противном случае, Jest не поймает ошибку за вас.

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

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

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

Спасибо за прочтение!

Присоединяйтесь к нашим каналам FrontEndDev и Web Stack в Telegram, чтобы не пропустить самое интересное из мира Web!