Software LEIC/LETI. Lecture 5

Size: px

Start display at page:

Download "Software LEIC/LETI. Lecture 5"

Amice Turner
5 years ago
Views:

1 Software LEIC/LETI Lecture 5

2 Last Lecture Verification and Validation Reviews and Inspections Software Testing Coverage Statement, branch, and path coverage Equivalence partitioning Boundary analysis

3 Today Test-first Types of tests Unit Testing Method testing Test doubles

4 Test-first

5 When can we start testing?

6 After the module is implemented

7 Why not before?

8 It is possible to review the requirements why?

9 Identify what to test

10 Test cases as specification!

11 How can we specify a method

12 The method signature it is not enough

13 Design-by-contract Eiffel language

14 < Method

15 Class

16 Test cases vs. Design-by-contract

17 a test case for put x=5, dictionary.count = 10, key= #1 assert(11,dictionary.count) assert(dictionary.get( #1 )==5)

18 A test case is an incomplete specification

19 What is the advantage of test-first?

20 Think before coding

21 Not afraid to modify the code regression testing

22 Can we use contracts to design test cases?

23 Use equivalence partitioning and boundary analysis

24 Types of tests

25 What is the best strategy to test a system?

26 Divide and Conquer

28 Development testing

29 Development testing Unit testing

30 Development testing Unit testing Component testing

31 Development testing Unit testing Component testing System testing

32 Development testing Unit testing Component testing System testing Release testing

33 Development testing Unit testing Component testing System testing Release testing User testing

34 Development testing Unit testing Component testing Developers System testing Release testing User testing

35 Development testing Unit testing Component testing Developers System testing Release testing QA Engineers User testing

36 Development testing Unit testing Component testing Developers System testing Release testing QA Engineers User testing Users

37 Unit Testing

38 What is the smaller part that can be tested?

39 From an OO perspective

40 Classes and their methods

41 What is an Object?

42 A cohesive set of data and behaviour

43 Test methods first

44 Example

46 Which methods should be tested?

48 Yes

49 Yes Yes

50 Yes Yes No, they are trivial

51 Yes Yes No, they are trivial Yes (ignore that the method is private)

52 Yes Yes No, they are trivial Yes (ignore that the method is private) Yes

53 Yes Yes No, they are trivial Yes (ignore that the method is private) Yes No, they are trivial

54 Yes Yes No, they are trivial Yes (ignore that the method is private) Yes No, they are trivial Yes

55 Yes Yes No, they are trivial Yes (ignore that the method is private) Yes No, they are trivial Yes No, it is trivial

56 Focusing in a particular invariant: code size is 4

57 Who changes the value of code?

59 Do we need to test checkcode?

60 Who invokes checkcode?

62 We can only test the constructor of Bank

64 Yes

65 Yes No

66 This decision was based on pragmatics complexity of methods, who invokes what, etc

67 Test cases for Bank constructor invariants to consider: name cannot be null, empty string or blanks string; code is unique and has size 4

68 class Bank { public Bank(String name, String code){ } name code result name OK code OK SUC null name code OK FAIL empty name code OK FAIL blank name code OK FAIL name OK null code FAIL name OK bank code FAIL name OK code size 3 FAIL name OK code size 5 FAIL name OK code exists FAIL

69 Success test case in JUnit

71 not checking the size of log

72 not checking the size of log testing vs visibility!

73 Can we test a class in isolation?

74 Object A Object B

75 Test A Object A Object B

76 Test A and B Object A Object B

77 What are the possible strategies?

78 Object A Object B

79 Test B Object A Object B

80 Test A and B Test B Object A Object B

81 Test A and B tests A and the interplay of A and B

82 Object A B Test Double

83 Test A Object A B Test Double

84 Test Doubles

86 isolate units

87 isolate units reduce dependencies between teams

88 isolate units reduce dependencies between teams reduce the overhead of testing set up, e.g. in memory databases

89 isolate units reduce dependencies between teams reduce the overhead of testing set up, e.g. in memory databases simulate infrequent, or difficult to generate, test cases, e.g. the server is down

90 Stubs and Mocks what are the differences

91 How to test a method that sends a message to an service? do not want to send s during tests

92 Stubs

93 public interface MailService { public void send (Message msg); } public class MailServiceStub implements MailService { private List<Message> messages = new ArrayList<Message>(); public void send (Message msg) { messages.add(msg); } } public int numbersent() { return messages.size(); } (

94 class OrderStateTester public void testordersendsmailifunfilled() { // set up Order order = new Order(TALISKER, 51); Warehouse warehouse = new Warehouse(); warehouse.setinventory(talisker, 50); MailServiceStub mailer = new MailServiceStub(); order.setmailer(mailer); // execute order.fill(warehouse); } // verify assertfalse(order.isfilled()) assertequals(1, mailer.numbersent()); (

95 Stubs are objects that provide a canned answer to calls made during the test

96 Stubs use state verification

97 Mocks

98 class OrderInteractionTester MailService public void testordersendsmailifunfilled() { // set up Order order = new Order(TALISKER, 51); Warehouse warehouse = new Warehouse(); warehouse.setinventory(talisker, 50); order.setmailer(mailer); new Expectations() {{ mailer.send((message) withnotnull()); }}; // execute order.fill(warehouse); } } // verify assertfalse(order.isfilled()); (adapted from

99 Are pre-programmed with expectations which form a specification of the calls they are expected to receive

100 Mocks use behaviour verification

CS159. Nathan Sprague. September 30, 2015

CS159. Nathan Sprague. September 30, 2015 CS159 Nathan Sprague September 30, 2015 Testing Happens at Multiple Levels Unit Testing - Test individual classes in isolation. Focus is on making sure that each method works according to specification.