diff options
Diffstat (limited to 'guides/source')
| -rw-r--r-- | guides/source/testing.md | 70 |
1 files changed, 12 insertions, 58 deletions
diff --git a/guides/source/testing.md b/guides/source/testing.md index 2067fdb383..230e8162f3 100644 --- a/guides/source/testing.md +++ b/guides/source/testing.md @@ -467,7 +467,6 @@ Rails adds some custom assertions of its own to the `minitest` framework: | `assert_generates(expected_path, options, defaults={}, extras = {}, message=nil)` | Asserts that the provided options can be used to generate the provided path. This is the inverse of assert_recognizes. The extras parameter is used to tell the request the names and values of additional request parameters that would be in a query string. The message parameter allows you to specify a custom error message for assertion failures.| | `assert_response(type, message = nil)` | Asserts that the response comes with a specific status code. You can specify `:success` to indicate 200-299, `:redirect` to indicate 300-399, `:missing` to indicate 404, or `:error` to match the 500-599 range. You can also pass an explicit status number or its symbolic equivalent. For more information, see [full list of status codes](http://rubydoc.info/github/rack/rack/master/Rack/Utils#HTTP_STATUS_CODES-constant) and how their [mapping](http://rubydoc.info/github/rack/rack/master/Rack/Utils#SYMBOL_TO_STATUS_CODE-constant) works.| | `assert_redirected_to(options = {}, message=nil)` | Assert that the redirection options passed in match those of the redirect called in the latest action. This match can be partial, such that `assert_redirected_to(controller: "weblog")` will also match the redirection of `redirect_to(controller: "weblog", action: "show")` and so on. You can also pass named routes such as `assert_redirected_to root_path` and Active Record objects such as `assert_redirected_to @article`.| -| `assert_template(expected = nil, message=nil)` | Asserts that the request was rendered with the appropriate template file.| You'll see the usage of some of these assertions in the next chapter. @@ -506,16 +505,18 @@ Now that we have used Rails scaffold generator for our `Article` resource, it ha Let me take you through one such test, `test_should_get_index` from the file `articles_controller_test.rb`. ```ruby +# articles_controller_test.rb class ArticlesControllerTest < ActionController::TestCase test "should get index" do get :index assert_response :success - assert_not_nil assigns(:articles) + assert_includes @response.body, 'Articles' end end ``` -In the `test_should_get_index` test, Rails simulates a request on the action called `index`, making sure the request was successful and also ensuring that it assigns a valid `articles` instance variable. +In the `test_should_get_index` test, Rails simulates a request on the action called `index`, making sure the request was successful +and also ensuring that the right response body has been generated. The `get` method kicks off the web request and populates the results into the response. It accepts 4 arguments: @@ -553,7 +554,7 @@ test "should create article" do post :create, params: { article: { title: 'Some title' } } end - assert_redirected_to article_path(assigns(:article)) + assert_redirected_to article_path(Article.last) end ``` @@ -580,11 +581,11 @@ To test AJAX requests, you can specify the `xhr: true` option to `get`, `post`, `patch`, `put`, and `delete` methods: ```ruby -test "ajax request responds with no layout" do +test "ajax request" do get :show, params: { id: articles(:first).id }, xhr: true - assert_template :index - assert_template layout: nil + assert_equal 'hello world', @response.body + assert_equal "text/javascript", @response.content_type end ``` @@ -592,20 +593,16 @@ end After a request has been made and processed, you will have 4 Hash objects ready for use: -* `assigns` - Any objects that are stored as instance variables in actions for use in views. * `cookies` - Any cookies that are set. * `flash` - Any objects living in the flash. * `session` - Any object living in session variables. -As is the case with normal Hash objects, you can access the values by referencing the keys by string. You can also reference them by symbol name, except for `assigns`. For example: +As is the case with normal Hash objects, you can access the values by referencing the keys by string. You can also reference them by symbol name. For example: ```ruby flash["gordon"] flash[:gordon] session["shmession"] session[:shmession] cookies["are_good_for_u"] cookies[:are_good_for_u] - -# Because you can't use assigns[:something] for historical reasons: -assigns["something"] assigns(:something) ``` ### Instance Variables Available @@ -633,46 +630,6 @@ get :index # simulate the request with custom header post :create # simulate the request with custom env variable ``` -### Testing Templates and Layouts - -Eventually, you may want to test whether a specific layout is rendered in the view of a response. - -#### Asserting Templates - -If you want to make sure that the response rendered the correct template and layout, you can use the `assert_template` -method: - -```ruby -test "index should render correct template and layout" do - get :index - assert_template :index - assert_template layout: "layouts/application" - - # You can also pass a regular expression. - assert_template layout: /layouts\/application/ -end -``` - -NOTE: You cannot test for template and layout at the same time, with a single call to `assert_template`. - -WARNING: You must include the "layouts" directory name even if you save your layout file in this standard layout directory. Hence, `assert_template layout: "application"` will not work. - -#### Asserting Partials - -If your view renders any partial, when asserting for the layout, you can to assert for the partial at the same time. -Otherwise, assertion will fail. - -Remember, we added the "_form" partial to our new Article view? Let's write an assertion for that in the `:new` action now: - -```ruby -test "new should render correct layout" do - get :new - assert_template layout: "layouts/application", partial: "_form" -end -``` - -This is the correct way to assert for when the view renders a partial with a given name. As identified by the `:partial` key passed to the `assert_template` call. - ### Testing `flash` notices If you remember from earlier one of the Four Hashes of the Apocalypse was `flash`. @@ -688,7 +645,7 @@ test "should create article" do post :create, params: { article: { title: 'Some title' } } end - assert_redirected_to article_path(assigns(:article)) + assert_redirected_to article_path(Article.last) assert_equal 'Article was successfully created.', flash[:notice] end ``` @@ -781,7 +738,7 @@ We can also add a test for updating an existing Article. test "should update article" do article = articles(:one) patch :update, params: { id: article.id, article: { title: "updated" } } - assert_redirected_to article_path(assigns(:article)) + assert_redirected_to article_path(article) end ``` @@ -820,7 +777,7 @@ class ArticlesControllerTest < ActionController::TestCase test "should update article" do patch :update, params: { id: @article.id, article: { title: "updated" } } - assert_redirected_to article_path(assigns(:article)) + assert_redirected_to article_path(@article) end end ``` @@ -857,7 +814,6 @@ class ProfileControllerTest < ActionController::TestCase get :show assert_response :success - assert_equal users(:david), assigns(:user) end end ``` @@ -1071,14 +1027,12 @@ How about testing our ability to create a new article in our blog and see the re test "can create an article" do get "/articles/new" assert_response :success - assert_template "articles/new", partial: "articles/_form" post "/articles", params: { article: { title: "can create", body: "article successfully." } } assert_response :redirect follow_redirect! assert_response :success - assert_template "articles/show" assert_select "p", "Title:\n can create" end ``` |