Use LEFT and RIGHT arrow keys to navigate between flashcards;
Use UP and DOWN arrow keys to flip the card;
H to show hint;
A reads text to speech;
19 Cards in this Set
- Front
- Back
|
What is Test Driven Development? |
A development approach which involves testing before writing any code. Three Stages: 1) Write a test for a proposed new bit of code. Run test, see it fail. 2) Write the code to fix the fail. 3) Run the test, see it succeed, refactor the code. 4) Move onto next increment. |
|
|
What is regression testing? What development process is it mainly used in?
|
Regression testing is ensuring new code added to software does not break old code previously functioning. Mainly used in TDD. |
|
|
Why does TDD make regression testing so simple? |
All code is tested at each small increment. Therefore adding a small increment with previous code all tested makes regression testing simple. |
|
|
What are the benefits of TDD? Red Car Don't Drive! |
1) Regression Testing: A regression test suite is developed incrementally as program is dev'd. 2) Code Coverage: All code is tested at least once due to testing at every increment. 3) Simple Debugging: As increments are so small, easy to find where the problem code is. 4) Good Documentation: The tests at each increment are also a form of documentation which describe what the code should be doing. |
|
|
What is Unit Testing?
|
Testing the smallest testable components of software in isolation. e.g. methods within an object |
|
|
Why use unit testing instead of testing software as a whole? |
1) Finding why bugs occur would be very hard as so many factors in a whole system. 2) Could be inter-operation bug or standalone unit bug. - Easier to track cause of problems in unit testing. |
|
|
What are the guidelines of unit testing? Self Isolation Consistently Seperates (me from frndz) |
1) Self-Descriptive variables, method names, assertion messages. 2) Isolation: Unit should not interact with actual resources. Test Doubles. Tests should be run in different order but produce the same result. 3) Consistency: Run tests multiple times behaving as expected. 4) Separate production code from testing code: Use test doubles to ensure prod code isn't affected. |
|
|
What are the 4 phases of Unit testing? |
1) Set Up 2) Execute 3) Verify 4) Teardown |
|
|
What is a test double and why is it used? |
A test double is used as a replacement for a DOC (dependent on component) where a SUT (system under test) needs to communicate with a separate component to function. The test double is not an exact replica but must provide same API. It is used so the test does not have to interact with actual resources. |
|
|
When should you use test doubles? |
1) Untested requirement which cannot be verified: e.g. need to test SUT indirect output. 2) Untested Code: e.g. need to test SUT indirect input. 3) Slow tests: test doubles enable quicker tests, more often. |
|
|
What are the types of test doubles? |
1) Dummy: empty object - to satisfy compiler 2) Fake: simplified version of DOC object 3) Stud: hardcoded object for certain behaviour 4) Spy: stud which also records info on how it was called. 5) Mock: object with programmed expected behaviour. used to verify interactions during lifetime. |
|
|
What is integration testing? |
Checks correct cooperation of subsystems. |
|
|
What are the four approaches of Integration Testing? |
Big Bang - all at once. not reocmmended. Bottom Up - Use Drivers to act as subsystems which call other subsystems. Test subsystems individually on bottom level. Then integrate with subsystems on next level together with those on bottom level that depend on them. Repeat until highest level. Top down is opposite of Bottom Up and uses Stubs instead of Drivers. Sandwich approach allows top and bottom layers to be tested in parallel. |
|
|
What are advs and disadvs of top down and bottom up integration testing methods? |
top down: advs: allows test on functional requirements - reveals early UI problems disadvs: lots of stubs which are difficult to write. bottom up: advs: no need to write stubs. easier to find bugs. disadvs: not good for revealing UI problems. |
|
|
What is component testing? |
Software components contain many objects. The functionality between these objects is the component interface. Component testing focuses on ensuring the component interface behaves as expected. |
|
|
What is interface testing? |
Testing to detect faults due to interface errors or assumptions about interfaces |
|
|
Name 4 interface types: PSPMessage |
1) Parameter: data passed from one procedure to another 2) Shared memory: block of memory shared between procedures or functions 3) Procedural: encapsulates set of procedures to be called by other sub systems 4) Message: subsystem request service from subsystem |
|
|
What are 3 potential interface errors? |
1) Timed Errors: called/calling components operate at diff speeds = out of data info. 2) Interface Misuse: calling component makes an error in its use of its interface e.g. parameters in wrong order 3) Interface Misunderstanding:calling component embeds incorrect assumptions about called components behaviour |
|
|
Name the 5 interface testing guidelines: |
1) extreme ends for parameters which are called 2) always test pointer/object params with a null pointer 3) design tests for component fails 4) stress stesting for message passing system 5) vary order in which components are activated in a shared memory system |
