Функциональное тестирование авторизации в направляющих
Я знаю, как выполнить функциональные / интеграционные тесты в направляющих, этот вопрос о лучших практиках. Скажем, авторизация выполняется с помощью четырех отличных пользовательских ролей:
- основной
- редактор
- администратор
- супер
Это означает, что для каждого действия существует до пяти различных возможных поведений (4 роли + не аутентифицируются/анонимные). Один подход, который я проявил, должен протестировать каждую роль на каждом действии, например:
test_edit_by_anonymous_usertest_edit_by_basic_usertest_edit_by_editor_usertest_edit_by_admin_usertest_edit_by_super_user
Но это, очевидно, приводит к большому количеству тестов (каждое действие контроллера с сайтом действительно должно быть протестировано пять раз). Противоположный подход должен был бы протестировать механизм авторизации в изоляции и затем пройти проверку подлинности как супер прежде, чем протестировать каждое действие (на установке) и только протестировать одну версию каждой страницы.
Я попробовал несколько подходов различными степенями специфики, но ничем не был абсолютно удовлетворен. Я чувствую себя более комфортно, когда я тестирую больше случаев, но сумма тестового кода и трудность абстракции были выключением. У кого-либо есть подход к этой проблеме, которой они удовлетворены?
2 ответа
Это действительно зависит от того, как вы настроили свой код для проверки авторизации и как вы проверяете его в действиях. Я могу рассказать вам, что мы делаем в качестве примера. У нас есть такие же роли, как и у вас, и некоторые страницы требуют входа в систему, некоторые требуют роли, а некоторые имеют разные результаты в зависимости от роли. Мы тестируем каждый тип по-своему.
Сначала мы проверяем авторизацию и вход в систему отдельно.
Кроме того, мы создали фильтры для действий, требующих входа пользователя в систему, а затем для других действий, требующих определенной роли. Например, check_admin , check_account_owner и т. Д. Затем мы можем проверить, что эти фильтры работают сами по себе.
Затем мы добавляем проверки в тесты контроллера, чтобы вызывались правильные фильтры. . Мы используем shoulda и написали несколько простых расширений, чтобы мы могли добавлять такие проверки, как:
should_filter_before_with :check_admin, :new
Таким образом, мы тестируем то, что нужно тестировать, и не более того.
Теперь, для более сложных действий, которые выполняют разную логику в зависимости от роли, мы тестируем эти действия для каждой роли, которая содержит особую логику. Мы не пишем тесты для ролей для этого действия, которое будет отфильтровано, или для надмножеств других ролей. Например, если действие добавляет дополнительные поля в форму, если вы являетесь администратором, мы тестируем пользователей без прав администратора и администратора. Мы не тестируем администратора и суперадминистратора, поскольку наш код для проверки ролей понимает, что суперадминистраторы являются администраторами.
Кроме того, для шаблонов, которые содержат логику для отображения только определенных элементов для определенных ролей, мы пытаемся переместить этот код в помощников , или, если это распространено, например, панель инструментов администратора, на частичные. Тогда мы сможем тестировать их самостоятельно, а не на каждом действии, которое их включает.
Подводя итог, можно сказать, что тестируйте только то, что вам нужно для данного действия. Точно так же, как вы не тестируете внутренние компоненты Rails в своих модульных тестах, если вы напишете общий код для проверки ролей и протестируете его, вам не нужно будет тестировать его снова при каждом действии.
В некоторых ситуациях от Вас может потребоваться проверка ВСЕХ возможных ролей и уровней авторизации на предмет различных действий - например, при работе в банке :) В этом случае имеет смысл использовать более динамичный подход к тестированию. Вместо того, чтобы определять каждый тестовый случай, вы будете генерировать все комбинации.
Несколько лет назад Райан Дэвис сделал презентацию о "матрице функционального тестирования", которая является частью ZenTest. Доктор Ник сделал запись, и в конце сообщения вы найдете обновленные ссылки в комментариях. Это решение было разработано именно для той проблемы, которую вы описываете. Вы также можете свернуть собственное решение, запустив тесты внутри вложенных циклов, например - идея в основном та же самая.
.