А вот дальше вопрос со звездочкой: как затестировать сортировку? Особенно если всё сделано как в примере: сортирует СУБД, а рисует уже фронт. Подводные камни: null значения в СУБД, если они позволяются, будут отдельно от пустых строк. А для пользователя они на фронте будут представлены одними и теми же пустыми строками. Возможно и для фронта тоже, если бэк забирая из БД станет нулл заменять пустой строкой. И это лишь один из нюансов.
Я вобщем пытался решать задачу в лоб. На уровне API и на фронте. В постмане или селениуме значит брал две ячейки и сравнивал: соответствуют ли они заданной сортировке. И это был неверный путь ибо JS (язык тестов постман) и Java совсем по разному справляются и сортируют если не внести кучу уточнений нежели это делает алгоритм в БД. А баги продолжали копиться! Или вот как в меме: тестировщика уволили за то что написал тест сортировки дней недели по алфавиту вместо Пн Вт Ср и т.д. 😁
В итоге пришел к осознанию, что лучше всего абстрагироваться от задачи и решать на приемочном уровне. Написал автотесты, которые проверяют 1. Нажатие на элемент сортировки формирует верный URL (column= и type=ASC например) 2. При отрисовке страницы после сортировки нет ошибок в консоли браузера 3. Упрощённое сравнение двух ячеек: если первая и последняя не совпадают при сортировке вниз - на их месте образуются другие при обратной сортировке (как бы например проверил и человек со слабым зрением, но без очков!) И все типовые баги отловились!
![Noob To Max With DRAGON REWORK In Blox Fruits [FULL MOVIE]](http://i.ytimg.com/vi/LnBMOinoOvA/mqdefault.jpg)
Меня аж трясет от того, на сколько крутой контент вы пилите. А можно больше такого контента с разными штуками на фронте описать?
Невероятно интересно
Топовая рубрика - кладезь знаний, спасибо, Герман!
ПУШКА ! тоже с этим мозги себе делал, потом дошло
А вот дальше вопрос со звездочкой: как затестировать сортировку? Особенно если всё сделано как в примере: сортирует СУБД, а рисует уже фронт. Подводные камни: null значения в СУБД, если они позволяются, будут отдельно от пустых строк. А для пользователя они на фронте будут представлены одними и теми же пустыми строками. Возможно и для фронта тоже, если бэк забирая из БД станет нулл заменять пустой строкой. И это лишь один из нюансов.
сравнить данные на фронте и результат запроса к БД?
@@user_name1_and_name2будешь 60 штук считать? А если сущностей 100/500/1000 на странице? Это же сколько времени уйдёт) Или я чего-то не понял?
@@HarikenTheWind ну я думаю достаточно ограничить выборку не обязательно
Первые и последние записи например
Я вобщем пытался решать задачу в лоб. На уровне API и на фронте. В постмане или селениуме значит брал две ячейки и сравнивал: соответствуют ли они заданной сортировке. И это был неверный путь ибо JS (язык тестов постман) и Java совсем по разному справляются и сортируют если не внести кучу уточнений нежели это делает алгоритм в БД. А баги продолжали копиться! Или вот как в меме: тестировщика уволили за то что написал тест сортировки дней недели по алфавиту вместо Пн Вт Ср и т.д. 😁
В итоге пришел к осознанию, что лучше всего абстрагироваться от задачи и решать на приемочном уровне.
Написал автотесты, которые проверяют
1. Нажатие на элемент сортировки формирует верный URL (column= и type=ASC например)
2. При отрисовке страницы после сортировки нет ошибок в консоли браузера
3. Упрощённое сравнение двух ячеек:
если первая и последняя не совпадают при сортировке вниз - на их месте образуются другие при обратной сортировке (как бы например проверил и человек со слабым зрением, но без очков!)
И все типовые баги отловились!