Комментарии 8
Теперь же представим себя разработчиком в вымышленной ИТ компании, перед которым стоит задача: написать валидатор пользовательских паролей
Как часто вам приходится писать валидаторы паролей? Вариант пореалистичнее: прототип какого-нибудь дашборда, который заказчик посмотрит, пощупает, выдаст правки, потом снова правки и в последующие 2-3 месяца всё будет переделано вдоль и поперёк.
Давно вынашивал схожие сомнения на этот счет.
Тезисно выразил в статье : https://habr.com/ru/articles/839658/
1234567890Password
Это сильный пароль по вашим оценкам.
Как пример для TDD может конечно пойти, но лучше было бы выбрать тему побезопасней.
У меня и так половина сайтов ругается что им то цифры, то символа не хватает в моих 16 символьных паролях сгенерированных password manager-ом. …
Давайте будем писать статьи про «нормальные» пароли исходя из реальных рекомендаций.
Если надо проверить пароль то надо проверять по базам хешей, а не по количеству символов.
Конкретно этот пароль было бы логично держать в файле dangerous_passwords.txt
Но вообще я не проводил ресерча по настоящим методам валидаций паролей, я понимаю, что там все сложнее, чем : 8 символов и спецзнак. Тут скорее я использовал стереотип, который был у меня в голове для примера. Я действительно брал эти условия с потолка. Прям совсем с потолка.
Ахахах, только на таких примерах все это тдд и работает, когда одна-две простых функции. Удачи делать тдд когда делается фича с интеграцией, емэйлами и другими сообщениями и событиями.
ИМХО, задача тестов, при TDD - это более правильно и корректно сформулировать задачу для разработчика функционала.
Публикации
Что такое TDD. Создаем валидатор паролей на регулярках