5

Rails で機能/統合テストを実行する方法を知っています。この質問はベスト プラクティスに関するものです。承認が 4 つの異なるユーザー ロールを使用して実行されるとします。

  • 基本
  • 編集者
  • 管理者
  • 素晴らしい

これは、アクションごとに最大 5 つの異なる動作が可能であることを意味します (4 つのロール + 非認証/匿名)。私がとったアプローチの 1 つは、すべてのアクションですべてのロールをテストすることです。次に例を示します。

  • test_edit_by_anonymous_user
  • test_edit_by_basic_user
  • test_edit_by_editor_user
  • test_edit_by_admin_user
  • test_edit_by_super_user

しかし、これは明らかに多くのテストにつながります (サイト上のすべてのコントローラー アクションは、実際には 5 回テストする必要があります)。反対のアプローチは、承認メカニズムを分離してテストし、すべてのアクションを (セットアップ時に) テストする前にスーパーとして認証し、各ページの 1 つのバージョンのみをテストすることです。

さまざまな程度の特異性でいくつかのアプローチを試しましたが、完全に満足できるものはありませんでした。より多くのケースをテストしていると、より快適に感じますが、テスト コードの量と抽象化の難しさには頭が下がります。誰もが満足しているこの問題へのアプローチを持っていますか?

4

3 に答える 3

4

これは、認証をチェックするためのコードをどのように設定したか、およびアクションでそれをどのようにテストしたかによって異なります。例として私たちが何をしているのかをお話しすることができます。あなたのような役割があり、ログインが必要なページ、役割が必要なページ、役割に基づいて出力が異なるページがあります。それぞれのタイプを少し異なる方法でテストします。

まず、認証とログインを別々にテストします。

また、ユーザーがログインしている必要があるアクションのフィルターを作成し、次に特定の役割を要求するアクションのフィルターを作成しました。たとえば、、check_adminなどcheck_account_owner。次に、これらのフィルタが単独で機能することをテストできます。

次に、コントローラーテストに、正しいフィルターが呼び出されていることを確認するチェックを追加します。shouldaを使用し、次のようなチェックを追加できるように簡単な拡張機能をいくつか作成しました。

should_filter_before_with :check_admin, :new

そうすることで、テストする必要があるものをテストし、それ以上テストする必要はありません。

ここで、役割に応じて異なるロジックを実行するより複雑なアクションについて、特別なロジックを含む役割ごとにそれらのアクションをテストします。フィルタリングされる、または他の役割のスーパーセットである、そのアクションの役割のテストは作成しません。たとえば、管理者の場合、アクションによってフォームにフィールドが追加されると、非管理者と管理者がテストされます。ロールチェックのコードはスーパー管理者が管理者であることを理解しているため、管理者とスーパー管理者はテストしません。

また、特定の役割の特定のアイテムのみを表示するロジックを含むテンプレートの場合、そのコードをヘルパーに移動するか、管理ツールバーのように一般的な場合はパーシャルに移動しようとします。次に、それらを含むすべてのアクションではなく、それらを独自にテストできます。

要約すると、特定のアクションに必要なものだけをテストします。単体テストでRailsの内部をテストしないのと同じように、役割チェック用の共通コードを記述してテストする場合は、すべてのアクションで再度テストする必要はありません。

于 2009-12-15T00:29:35.143 に答える
2

In some situations you may be required to test ALL possible roles and authorization levels against different actions - like, when working for a bank, for instance :) In this case it makes sense to take a more dynamic approach to testing. Instead of defining each test case, you would generate all the combinations.

A few years ago Ryan Davis did a presentation about the "functional test matrix" which is part of ZenTest. Dr. Nic did a writeup, and at the end of the post you'll find updated links in the comments. This solution was designed for exactly the problem you describe. You could also roll your own solution, by running tests inside nested loops, for example - the idea is basically the same.

于 2009-12-22T22:57:15.303 に答える
0

管理者ロールと読み取り専用ロールの 2 つのアプリケーションを考えてみましょう。以下のテストを実行します。

  1. 読み取り専用モードでログインすると、何らかのアクションが実行され、ログアウトされます。同じシステムと同じブラウザから管理者ロールでログインし、システムの動作を確認します。およびその逆。
  2. admin ロールでログインし、Cookie の値をコピーしてログアウトします。通常のロールでログインし、cookimanager+ または editthiscookie ツールを使用して Cookie の値を編集します。そして、アプリケーションが期待どおりに機能している場合、それは問題です。上記のテスト ケース 2 を同じマシンから、同じブラウザーから、同じマシンから、別のブラウザーから、別のマシンから繰り返します。
  3. シック クライアント アプリケーションの場合は、リバース エンジニアリングを実行してコードを分析します。承認管理のロジックを変更してみてください (これにはコーディングの経験が必要です)。コードを再コンパイルし、テスト 2 ～ 3 を繰り返します。
  4. Burp Suite のようなプロキシ中断ツールを使用して、両方のロールの get/post リクエストを分析します。

アプリケーションで使用可能なロールのタイプに基づいて、テスト ケースを決定します。

于 2017-01-08T04:34:12.867 に答える