NB
Size: a a a
2021 February 11
AV
страница проанализирована: она говно.
Страница говно, но это страница.
A
вопрос в другом:
должна ли страница обновляться при нажатии на этот логотип
должна ли страница обновляться при нажатии на этот логотип
А что открывается, когда переходишь по урлу cupid.com? В порнорежиме, например?
i
так классы эквивалентности же по тестовым данным, а не по результату у тебя будут?
к слову, то, что у тебя на фронте выглядит одинаково, может (и должно, кстати) быть разным кодом ошибки на бэкенде
к слову, то, что у тебя на фронте выглядит одинаково, может (и должно, кстати) быть разным кодом ошибки на бэкенде
по-моему никто сейчас не делает разные коды ошибок на такие вещи как - существует почта или не существует при попытке авторизоваться - это ж не секьюрно?
я говорю человеку снаружи что аккаунт с такой то почтой существует -
я говорю человеку снаружи что аккаунт с такой то почтой существует -
A
i think it's okay
по-моему никто сейчас не делает разные коды ошибок на такие вещи как - существует почта или не существует при попытке авторизоваться - это ж не секьюрно?
я говорю человеку снаружи что аккаунт с такой то почтой существует -
я говорю человеку снаружи что аккаунт с такой то почтой существует -
Падажжи. Я - про невалидный адрес почты и валидный, но несуществующий
EB
i think it's okay
если в ситуации когда в поле login ввели не существующий логин, не существующий email, не корректный логин( русские символы) и некорректную почту - если во всех этих случаях мы получаем один ответ - invalid login or password - имеет ли смысл играться с классами эквивалентности и граничными значениями на этой форме?
т.е все эти вещи как будто можно проверить на этапе регистрации
т.е все эти вещи как будто можно проверить на этапе регистрации
ну во-первых поле регистрации и поле логина эта разные формы. и на них могут быть разные валидации, потому что на бекенде это разные контроллеры
во-вторых, если на фронте для любой из некорректных данных есть только один вид ошибки, но внутри оно все равно обрабатывается по разным кейсам, то проверить все равно нужно на все сценарии. Хотя бы потому, что когда-нибудь на один из вид ошибок отдельно что-то сделают, а у тебя тест упадет и станет понятно, что нужно и тест обновить.
во-вторых, если на фронте для любой из некорректных данных есть только один вид ошибки, но внутри оно все равно обрабатывается по разным кейсам, то проверить все равно нужно на все сценарии. Хотя бы потому, что когда-нибудь на один из вид ошибок отдельно что-то сделают, а у тебя тест упадет и станет понятно, что нужно и тест обновить.
EB
Коррект ми иф айм ронг, но ошибки от asd@.cc и asd@bb.cc должны быть разными
при логине сервис не берет себе задачу провалидировать имейл обычно на то, является он валидным или нет.
в 99/100 случаев при логине делается что-то вида
select * from emails where email == user_email limit 1
то есть зачем сервису при логине что-то там валидировать? он ищет точное соответствие имейла в базе
в 99/100 случаев при логине делается что-то вида
select * from emails where email == user_email limit 1
то есть зачем сервису при логине что-то там валидировать? он ищет точное соответствие имейла в базе
EB
то есть валидация на корректность имейла важна для консистености данных при регистрации. например, могут быть тестовые данные которые миграцией занесены в БД и не соотвествуют нормам регистрации, и теперь что, при логине в эти учетки не пускать их в сервис за то, что они не удовлетворяют правилам при регистрации? =)
DK
Наконец-то сайты знакомств, но без обсуждения девок