Как проверять окраску поля в зависимости от суммы в калькуляторе
Что проверяют
Умеете ли вы проверять визуальное состояние элемента в автотесте, не скатываясь в сравнение пикселей. Главное, что хотят услышать: где пороги сумм и как вы выбираете значения вокруг них. Следом спрашивают, что делать, если цвет меняется с анимацией.
Как отвечать
Сначала выясните требование: какие диапазоны, какие цвета, входит ли граница. «До 10 000 зелёный, от 10 000 жёлтый» и «больше 10 000 жёлтый» расходятся ровно на пороге.
Затем проверки по уровням:
- логика: если выбор цвета вынесен в функцию, покрывайте её юнит-тестами через
@pytest.mark.parametrize: сама граница, на копейку ниже и выше, ноль, отрицательная сумма, пустой ввод. Это быстро и не зависит от браузера; - UI в браузере: в Playwright для Python есть
expect(locator).to_have_css("background-color", "rgb(255, 0, 0)"), проверка сама дождётся нужного значения, что спасает при CSS-анимации. В Selenium этоelement.value_of_css_property("background-color"), строкуrgba(...)придётся нормализовать и ждать явно; - класс вместо цвета: если фронтенд переключает CSS-класс (
is-warning,is-error), надёжнее проверить класс черезto_contain_class. Тест не сломается, когда дизайнер поменяет оттенок; - пересчёт: цвет должен меняться при любом изменении суммы, в том числе при удалении символов и вставке из буфера, а не только по кнопке.
Отдельно упомяните доступность: цвет не должен быть единственным сигналом (критерий WCAG 1.4.1), рядом нужны иконка или текст. Это показывает, что вы думаете о пользователе, а не только о селекторе.
Где спотыкаются
Пишут само приложение на Tkinter вместо тестов к нему. Вопрос про проверку, и интервьюер ждёт тест-дизайн и ассерты, а не реализацию калькулятора.
Сравнивают цвет с hex из макета, например #FF0000. Браузер отдаёт вычисленное значение в rgb() или rgba(), и тест падает на формате, хотя цвет верный.
Берут значения из середины диапазонов, 500 и 50 000, и пропускают саму границу. Ошибка «> вместо >=» живёт как раз на пороге и в копейке рядом с ним.