Skip to content
Katrin edited this page Dec 22, 2015 · 1 revision

Ruby Monstas 23.11.2015 protocol by Johanna

Last week, we were testing models (unit testing), this week it is going to be : Controllers!

  • Controller Tests are conceptually different from those we ran last week, they are functional tests
  • Goal: response from server with:
  • status code (200: sucess messages; 400 or 500: error messages)
  • headers
  • maybe body (html)
  • CT tests more stack; pretending to be a user and send a request
  • you don't just test one action
  • Test example: ask for event 1, then responses should be: status code 200 and html Text
  • Exercise: create event and application with acceptable data
  • Joe created an example test on Git Hub
  • pretend to be user: send GET request :show for particular event and application via id
  • „admin_login“: pretend, that user is logged in

INFO: Rails Guide Controller Test > Functional test

they test e.g.:

  • was the web request successful?
  • was the user redirected to the right page?
  • was the user successfully authenticated?
  • was the correct object stored in the response template?
  • was the appropriate message displayed to the user in the view?

Functional tests are: very diverse; no convention agreed on what exactly to test usually you work with assertions testing response code is a decent start :)

We fetch Joe's example from GitHub. We copy a test in the applications-controller. Then we delete the admin login. We want to test, what non-admins can see. Run test „Show application to users“: works Run test „Ask for event, that doesn't exist“ (pass wrong ID) here we work with assert_raises (ActiveRecord::RecordNotFound)

Run test „raise exception if application does not exist“ we don't need to be logged in use post helper we have to post the minimum information because of the validations

Some developers actually write the test before the code! This helps you decide the functionality of your code before you write it. (Makes you think about what you want to do with your application, before building it.) If you test the code only afterwards, like we did, then it might seem pointless, since you'd be testing code that has been working for a while already.