{
    "content": [
        {
            "type": "text",
            "text": "# ActionDispatch::IntegrationTest (ri)\n\n## Sections\n\n- **ActionDispatch::IntegrationTest < ActiveSupport::TestCase**\n- **Includes:**\n\nUse structuredContent.sections for detailed options, examples, and full documentation.\n"
        }
    ],
    "structuredContent": {
        "command": "ActionDispatch::IntegrationTest",
        "section": "",
        "mode": "ri",
        "summary": null,
        "synopsis": null,
        "tldr_summary": null,
        "tldr_examples": [],
        "tldr_source": null,
        "flags": [],
        "examples": [],
        "see_also": [],
        "section_outline": [
            {
                "name": "ActionDispatch::IntegrationTest < ActiveSupport::TestCase",
                "lines": 1,
                "subsections": []
            },
            {
                "name": "Includes:",
                "lines": 201,
                "subsections": []
            }
        ],
        "sections": {
            "ActionDispatch::IntegrationTest < ActiveSupport::TestCase": {
                "content": "------------------------------------------------------------------------",
                "subsections": []
            },
            "Includes:": {
                "content": "(from /home/chedong/.local/share/rdoc)\nTestProcess::FixtureFile\nBehavior\n\n(from /home/chedong/.local/share/rdoc)\n------------------------------------------------------------------------\nAn integration test spans multiple controllers and actions, tying them\nall together to ensure they work together as expected. It tests more\ncompletely than either unit or functional tests do, exercising the\nentire stack, from the dispatcher to the database.\n\nAt its simplest, you simply extend IntegrationTest and write your tests\nusing the get/post methods:\n\nrequire \"testhelper\"\n\nclass ExampleTest < ActionDispatch::IntegrationTest\nfixtures :people\n\ndef testlogin\n# get the login page\nget \"/login\"\nassertequal 200, status\n\n# post the login and follow through to the home page\npost \"/login\", params: { username: people(:jamis).username,\npassword: people(:jamis).password }\nfollowredirect!\nassertequal 200, status\nassertequal \"/home\", path\nend\nend\n\nHowever, you can also have multiple session instances open per test, and\neven extend those instances with assertions and methods to create a very\npowerful testing DSL that is specific for your application. You can even\nreference any named routes you happen to have defined.\n\nrequire \"testhelper\"\n\nclass AdvancedTest < ActionDispatch::IntegrationTest\nfixtures :people, :rooms\n\ndef testloginandspeak\njamis, david = login(:jamis), login(:david)\nroom = rooms(:office)\n\njamis.enter(room)\njamis.speak(room, \"anybody home?\")\n\ndavid.enter(room)\ndavid.speak(room, \"hello!\")\nend\n\nprivate\n\nmodule CustomAssertions\ndef enter(room)\n# reference a named route, for maximum internal consistency!\nget(roomurl(id: room.id))\nassert(...)\n...\nend\n\ndef speak(room, message)\npost \"/say/#{room.id}\", xhr: true, params: { message: message }\nassert(...)\n...\nend\nend\n\ndef login(who)\nopensession do |sess|\nsess.extend(CustomAssertions)\nwho = people(who)\nsess.post \"/login\", params: { username: who.username,\npassword: who.password }\nassert(...)\nend\nend\nend\n\nAnother longer example would be:\n\nA simple integration test that exercises multiple controllers:\n\nrequire \"testhelper\"\n\nclass UserFlowsTest < ActionDispatch::IntegrationTest\ntest \"login and browse site\" do\n# login via https\nhttps!\nget \"/login\"\nassertresponse :success\n\npost \"/login\", params: { username: users(:david).username, password: users(:david).password }\nfollowredirect!\nassertequal '/welcome', path\nassertequal 'Welcome david!', flash[:notice]\n\nhttps!(false)\nget \"/articles/all\"\nassertresponse :success\nassertselect 'h1', 'Articles'\nend\nend\n\nAs you can see the integration test involves multiple controllers and\nexercises the entire stack from database to dispatcher. In addition you\ncan have multiple session instances open simultaneously in a test and\nextend those instances with assertion methods to create a very powerful\ntesting DSL (domain-specific language) just for your application.\n\nHere's an example of multiple sessions and custom DSL in an integration\ntest\n\nrequire \"testhelper\"\n\nclass UserFlowsTest < ActionDispatch::IntegrationTest\ntest \"login and browse site\" do\n# User david logs in\ndavid = login(:david)\n# User guest logs in\nguest = login(:guest)\n\n# Both are now available in different sessions\nassertequal 'Welcome david!', david.flash[:notice]\nassertequal 'Welcome guest!', guest.flash[:notice]\n\n# User david can browse site\ndavid.browsessite\n# User guest can browse site as well\nguest.browsessite\n\n# Continue with other assertions\nend\n\nprivate\n\nmodule CustomDsl\ndef browsessite\nget \"/products/all\"\nassertresponse :success\nassertselect 'h1', 'Products'\nend\nend\n\ndef login(user)\nopensession do |sess|\nsess.extend(CustomDsl)\nu = users(user)\nsess.https!\nsess.post \"/login\", params: { username: u.username, password: u.password }\nassertequal '/welcome', sess.path\nsess.https!(false)\nend\nend\nend\n\nSee the request helpers documentation(\nrdoc-ref:ActionDispatch::Integration::RequestHelpers ) for help on how\nto use get, etc.\n\n=== Changing the request encoding\n\nYou can also test your JSON API easily by setting what the request\nshould be encoded as:\n\nrequire \"testhelper\"\n\nclass ApiTest < ActionDispatch::IntegrationTest\ntest \"creates articles\" do\nassertdifference -> { Article.count } do\npost articlespath, params: { article: { title: \"Ahoy!\" } }, as: :json\nend\n\nassertresponse :success\nassertequal({ id: Article.last.id, title: \"Ahoy!\" }, response.parsedbody)\nend\nend\n\nThe as option passes an \"application/json\" Accept header (thereby\nsetting the request format to JSON unless overridden), sets the content\ntype to \"application/json\" and encodes the parameters as JSON.\n\nCalling parsedbody on the response parses the response body based on\nthe last response MIME type.\n\nOut of the box, only :json is supported. But for any custom MIME types\nyou've registered, you can add your own encoders with:\n\nActionDispatch::IntegrationTest.registerencoder :wibble,\nparamencoder: -> params { params.towibble },\nresponseparser: -> body { body }\n\nWhere paramencoder defines how the params should be encoded and\nresponseparser defines how the response body should be parsed through\nparsedbody.\n\nConsult the Rails Testing Guide for more.\n------------------------------------------------------------------------",
                "subsections": []
            }
        }
    }
}