CSC/ECE 517 Fall 2012/ch2a 2w30 an: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
No edit summary |
||
| Line 11: | Line 11: | ||
**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. | **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: | *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. | **Testing field has changed considerably. Where [http://en.wikipedia.org/wiki/Software_quality_assurance 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: | *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. | **Testing should follow the [http://en.wikipedia.org/wiki/Test-driven_development 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. | ||
=Rspec= | =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. 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 specialized. | |||
* | |||
DSL for writing test – small programming lang that does only a small number of tasks within a task domain – specialized – Migrations – small set of statements- sole job to express changes in database schema – ruby code stylized to look like the tasks they do – embedded ruby code – Rspec – internal DSL – implemented inside another language – SQL – stand alone DSL | |||
=Conclusion= | =Conclusion= | ||
Revision as of 00:01, 27 October 2012
SaaS - 5.2 - FIRST, TDD and getting started with RSpec
Introduction
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.
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. 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 specialized.
DSL for writing test – small programming lang that does only a small number of tasks within a task domain – specialized – Migrations – small set of statements- sole job to express changes in database schema – ruby code stylized to look like the tasks they do – embedded ruby code – Rspec – internal DSL – implemented inside another language – SQL – stand alone DSL