CSC/ECE 517 Fall 2012/ch2a 2w30 an

SaaS - 5.2 - FIRST, TDD and getting started with RSpec

Characteristics of a good Unit test

• Fast:
  • The tests should not take too long to run. Sometimes it would seem more logical to run only a subset of the tests (for example, when a part of the code breaks or only a particular functionality of the code is being developed). In such cases, it would not be productive if the tests take quite a bit of time to finish executing.
• Independent:
  • When tests are being run, the order of execution of the tests should not matter. More importantly, tests should not be inter-dependent; which means that, it should be possible to run any subset of the test set in any order. Also, no test should be a prerequisite for another test.
• Repeatable:
  • The output for a test execution should be consistent irrespective of the number of times that it is run. This is essential in order to isolate bugs and enable automation. If the test notices the presence of a bug on the first run, it should do so on every consecutive run.
• Self-checking:
  • Testing field has changed considerably. Where Quality Assurance department was involved to check the functionality of the code, it is now all automated. It is therefore, now mandatory that all tests themselves know if it is a pass or fail. No human intervention should be expected. Also, tests can run in the back all the time which means that if there is a change in the code or when the code breaks, the test script should be able to identify the same without human intervention.
• Timely:
  • Testing should follow the Test Driven Development (TDD) approach. Here, the test cases are written before the code is implemented or at least around the same time (and not after!). Hence, if the functionality of the code being tested changes, the respective test cases should change correspondingly.

DSL

DSLs are small programming languages that do only a small number of activities within a specific task domain. Thus we can say that a DSL is not general. Examples for DSLs include migration scripts (which are a small set of statements with the sole job of expressing changes in the database schema), Regexes, SQL.

RSpec

[RSpec] is a testing tool for [Ruby][1]. It is based on [Behavior Driven Development(BDD)] framework and is inspired by [JBehave] which is another BDD testing framework[2]. RSpec is considered a [Domain Specific Language(DSL)] for writing tests. The notable difference between RSpec and SQL is that, while RSpec is an internal DSL, SQL is stand alone. Internal or embedded DSLs are implemented within another language that acts as their host.[]

Features of RSpec

• Each test in RSpec is called a spec (which is short for specification).
• RSpec code inhabits the Spec directory which mimics the directory structure of the application.rspec:install is a [Rails generator] that creates the sub-directory structure for the Spec directory.
• Specs are usually written for the controller and model methods. View spec checking is done mostly using the controller spec (seeing that the view will call controller method) and so, specs are usually not written for view. Instead, one can use [Cucumber] to test the view functionality.

The code you wish you had – Seam – when the user clicks on the button in the view for search_tmdb – controller action receives the form submission – It then calls a model method to check the database to see if the entered value exists. Movie found – render view with search results – else homepage with an error or message