Methods 4.

1. Methods 4. 0. Take in assignment 5. 1. Review. 2. Stubs and drivers. 3. Unit testing and integration testing.

2. 1. Review. • (1) Class-wide versus local variables: what is the distinction? • (2) What are local variables? Local to what? • (3) Where can local variables be accessed? • (4) Where can class-wide variables be accessed?

3. Why use… • Local variables? • Class-wide variables? • When is NOT a good idea to use a local variable? • When is it NOT a good idea to use a class-wide variable?

4. Why does C# ban global variables? • What is the danger of global variables? • Why do we pass parameters? • How can we avoid excessive parameter passing?

5. 2. Stubs and drivers. • Key idea of testing programs with methods: • The “building block” approach. • Using methods, (1) one can build programs block by block and (2) one can test each block before going on to the next block. • See diagrams.

6. Stubs and drivers (cont.). • Why do it this way? • As much as possible we can eliminate errors before moving on to the next stage. Like a builder who wants to be sure the foundation is sound, then the walls, then the roof. • If an error is found at a later stage, it was probably caused by a later module.

7. Stubs and drivers (cont.). • But, how can we test individual methods? • Need to be able to run methods independently. • This uses the idea of “stubs and drivers.” • First create a driver = a skeleton Main program that can be used to call just the method(s) you want to test.

8. Stubs and drivers (cont.). • If a given method requires input from elsewhere (including input derived from another method), this can be simulated by sending dummy values to the method. • Then, one can code “stubs” for other methods. A stub=a method with an interface, but without a full implementation.

9. Stubs and drivers (cont.). • A stub may contain “a trace statement” e.g. “method X entered OK.” This can be used to test the logical structure of the program, to see if various pathways are followed correctly. For example one can check if the method is called if, and only if a certain condition is true.

10. Stubs and drivers (cont.). • One can also develop any of the stubs by filling in the implementation, one method at a time, and testing it. • Why? What is the advantage?

11. 3. Unit testing and integration testing. • Unit testing: testing each method separately as a method? • Why? • Analogy: checking that all of the parts for a model airplane / Bionicle are sound. • Unless each of the parts is sound, no chance that the whole will be.

12. Unit testing and integration testing (cont.). • But unit testing is not enough. • Why? • Just because each part is sound, does not mean that the whole will be (fallacy of composition). Why? • Compare: all players passed their fitness test / all of these are trained actors.

13. Unit testing and integration testing (cont.). • So, in addition to unit testing, need integration testing: checks that all of the modules (1) are correctly coordinated; (2) interface (communicate) correctly. Note that methods have pre-conditions (what should be true before the method is called) and postconditions.

14. Unit testing and integration testing (cont.). • The postconditions of an earlier method should be the preconditions of the next method. Analogy with soccer: one player needs to make a pass which “sets up” the next player for his play. • E.g. the preconditions of a calculation method are that all givens have been input and any values to calculate have been initialized (to zero or other initial value).