📌 Шпаргалка по работе с ветками и сохранению изменений в Git

В ней собраны основные команды для эффективного управления ветками и фиксации правок:

➡️ Просмотр и переключение веток

➡️ Создание и удаление веток

➡️ Слияние и тегирование

➡️ Добавление изменений и коммиты

➡️ Отмена изменений

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

🐸 Библиотека тестировщика

#буст

⭐️ Как протестировать асинхронные экшены в Redux

Асинхронные экшены в Redux обрабатывают API-запросы и диспатчат действия по результату. Их можно проверить без UI — через мок-хранилище и анализ последовательности.

Почему важно:

📍 Проверка цепочки: запуск → результат → обработка

📍 Контроль над данными и ошибками

📍 Возможность изолировать бизнес-логику от UI

Как протестировать:

1. Установим зависимости:

npm install redux-mock-store redux-thunk --save-dev

2. Создадим мок-хранилища:

import configureStore from 'redux-mock-store';
import thunk from 'redux-thunk';

const store = configureStore([thunk])();

3. Пример экшена:

export const fetchData = () => async dispatch => {
  dispatch({ type: 'FETCH_START' });
  try {
    const res = await fetch('/api/data');
    const data = await res.json();
    dispatch({ type: 'FETCH_SUCCESS', payload: data });
  } catch (e) {
    dispatch({ type: 'FETCH_ERROR', error: true });
  }
};

4. Позитивный сценарий:

it('dispatches FETCH_START и FETCH_SUCCESS', async () => {
  global.fetch = jest.fn(() =>
    Promise.resolve({ json: () => Promise.resolve({ name: 'test' }) })
  );

  await store.dispatch(fetchData());

  const actions = store.getActions();
  expect(actions).toEqual([
    { type: 'FETCH_START' },
    { type: 'FETCH_SUCCESS', payload: { name: 'test' } }
  ]);
});

5. Негативный сценарий (сетевая ошибка):

it('dispatches FETCH_ERROR при сбое запроса', async () => {
  global.fetch = jest.fn(() => Promise.reject('Network error'));

  await store.dispatch(fetchData());

  const actions = store.getActions();
  expect(actions).toEqual([
    { type: 'FETCH_START' },
    { type: 'FETCH_ERROR', error: true }
  ]);
});

Что проверяет тестировщик:

— Последовательность действий

— Корректность переданных данных

— Обработку ошибок и fallback-поведение

— Отсутствие лишних или пропущенных экшенов

💡 Такие проверки позволяют выявлять ошибки бизнес-логики без зависимости от UI. Это удобно при регрессионном тестировании, CI и тестировании без доступа к фронту.

🐸 Библиотека тестировщика

#буст

🥹🥹

🐸 Библиотека тестировщика

#развлекалово

🖥️ Как проверить адаптивность приложения для нестандартных разрешений экрана

При тестировании приложений часто забывают про экраны с необычными разрешениями, например, 800x600 или 5K. Эти размеры требуют отдельного подхода, чтобы убедиться, что интерфейс остаётся функциональным и красивым на всех типах устройств.

Промпт:

How can I check the responsiveness of my application for screen resolutions that are rarely used (e.g., 800x600 or 5K)? What testing tools and
methods should be applied for these screen sizes?

Чем полезен:

➡️ Проверяет, как приложение ведет себя на экранах с редкими разрешениями

➡️ Помогает выявить проблемы с отображением и интерфейсом на разных типах экранов

➡️ Рекомендует методы тестирования, включая эмуляцию и использование инструментов

Дополнительно можно запросить:

— Как настроить медиа-запросы для таких разрешений

— Использование инструментов, таких как Chrome DevTools, для проверки адаптивности

— Рекомендации по улучшению интерфейса для редких экранов

🐸 Библиотека тестировщика

#буст

🕚 Почему баги в часовых поясах важнее, чем кажется

Наш подписчик поделился интересной историей:

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

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

❓ Были ли у вас такие проблемы с часовыми поясами? Как вы с ними справлялись?

🐸 Библиотека тестировщика

#междусобойчик

Как относитесь к созданию своего жпт не через конструктор, а хардкорно через код?

🔥 — я своего завайбкодил

🏃‍♀️ Ссылка на курс

😏 Фишка инструмента: кэширование авторизации между тестами

Cypress позволяет сохранять и восстанавливать сессию (cookies, localStorage, sessionStorage) при помощи команды cy.session(), чтобы логин не выполнялся перед каждым it. Это ускоряет тесты и делает их стабильнее.

Что еще полезного:

✅ Ускоряет тесты — логин происходит единожды, остальные кейсы используют сохранённую сессию

✅ Удобно для крупных e2e-сценариев с авторизацией

✅ Поддерживает несколько сессий по разным ключам (пример: для разных ролей пользователя)

Как настроить:

beforeEach(() => {
  cy.session(['[email protected]', '123456'], () => {
    cy.visit('/login')
    cy.get('input[name="email"]').type('[email protected]')
    cy.get('input[name="password"]').type('123456')
    cy.get('button[type="submit"]').click()
    cy.url().should('contain', '/dashboard')
  }, {
    cacheAcrossSpecs: false
  })
  cy.visit('/dashboard')
})

➡️ cy.session() — кэширует сессию по идентификатору (массив или строка)

➡️ На следующий it Cypress восстановит сессию, минуя повторный логин

➡️ После cy.session() обязательно добавляйте cy.visit(), чтобы перейти на нужную страницу

💡 Дополнительно:

— Используйте cacheAcrossSpecs: true, чтобы сессия сохранялась между spec-файлами при запуске cypress run --browser electron (но могут быть нюансы с Chrome)

— Для валидации сессии можно добавить validate() опцию: при неуспехе — сессия пересоздаётся

— Cypress.session API позволяет отслеживать и очищать, если необходимо

🐸 Библиотека тестировщика

#буст