Как стать автором
Поиск
Написать публикацию
Обновить

Комментарии 9

Теперь же представим себя разработчиком в вымышленной ИТ компании, перед которым стоит задача: написать валидатор пользовательских паролей

Как часто вам приходится писать валидаторы паролей? Вариант пореалистичнее: прототип какого-нибудь дашборда, который заказчик посмотрит, пощупает, выдаст правки, потом снова правки и в последующие 2-3 месяца всё будет переделано вдоль и поперёк.

Давно вынашивал схожие сомнения на этот счет.
Тезисно выразил в статье : https://habr.com/ru/articles/839658/

1234567890Password

Это сильный пароль по вашим оценкам.

Как пример для TDD может конечно пойти, но лучше было бы выбрать тему побезопасней.

У меня и так половина сайтов ругается что им то цифры, то символа не хватает в моих 16 символьных паролях сгенерированных password manager-ом. …

Давайте будем писать статьи про «нормальные» пароли исходя из реальных рекомендаций.

Если надо проверить пароль то надо проверять по базам хешей, а не по количеству символов.

Конкретно этот пароль было бы логично держать в файле dangerous_passwords.txt

Но вообще я не проводил ресерча по настоящим методам валидаций паролей, я понимаю, что там все сложнее, чем : 8 символов и спецзнак. Тут скорее я использовал стереотип, который был у меня в голове для примера. Я действительно брал эти условия с потолка. Прям совсем с потолка.

Ахахах, только на таких примерах все это тдд и работает, когда одна-две простых функции. Удачи делать тдд когда делается фича с интеграцией, емэйлами и другими сообщениями и событиями.

Обычно архитектура и разделение на слои хорошо в этом случае работает

ИМХО, задача тестов, при TDD - это более правильно и корректно сформулировать задачу для разработчика функционала.

У нас тут как раз такой тест: более правильно сформулировать задачу.

В итоге автор реализовал проверку паролей с помощью regexp, и как мы вроде все согласились результат не очень. И надо было по списку общеизвестных паролей пройти.

Как TTD помог в решении проблемы?

Для TDD итерации крупноваты. Тесты слишком большие и не имеют однозначного соответствия требованиям.

Для соответствия требованиям я бы предложил следующий набор тестов:

  • IncorrectPasswordIsLessThan8CharactersLong

  • IncorrectPasswordIsMoreThan22CharactersLong

  • IncorrectPasswordContainsNonLatinLetters

  • IncorrectPasswordContainsNoSpecialCharacters

  • WeakPasswordContainsNoLetters

  • WeakPasswordIs8CharactersLong

  • MediumPasswordContainsNoNumerics

  • MediumPasswordIsLessThan10CharactersLong

  • MediumPasswordContainsOnlyOneNumericAtTheEnd

  • PasswordIsStrong

Каждый тест проверяет только одно условие, закрывает конкретное требование спецификации и соответствует полной итерации. После написания каждого теста убеждаемся, что он не проходит, и делаем минимальную реализацию с последующим рефакторингом.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации