TEST DRIVEN DEVELOPMENT VS DESIGN BY CONTRACT

Transcription

1 TEST DRIVEN DEVELOPMENT VS DESIGN BY CONTRACT prof. Carlo Bellettini

2 Perhaps it is not a so silly question...

3 SUMMARY Simple presentation of Demo of The comparison between e

4 make the code simpler, nice to see, you have to be proud of your code :-D MANTRA

5 SOME INFO the name is misleading some one suggested to use Instead of Test Driven Development someone suggested to call it Behavioral Driven Development The main goal is a design goal... not a verification goal There are complex interaction with other extreme Programming practices

6 REFACTORING another way to exercise is to use some calisthenics rule... The code is simple enough when it: 0. Runs all the tests 1. Expresses every idea that we need to express 2. Contains no duplication 3. Has the minimum number of classes and functions (In this order)

7 HOW TO CHECK IT? The classical suggested way is: exercise yourself with a Kata

8 BOWLING KATA The game consists of 10 frames as shown above. In each frame the player has two opportunities to knock down 10 pins. The score for the frame is the total number of pins knocked down, plus bonuses for strikes and spares. A spare is when the player knocks down all 10 pins in two tries. The bonus for that frame is the number of pins knocked down by the next roll. So in frame 3 above, the score is 10 (the total number knocked down) plus a bonus of 5 (the number of pins knocked down on the next roll.) A strike is when the player knocks down all 10 pins on his first try. The bonus for that frame is the value of the next two balls rolled. In the tenth frame a player who rolls a spare or strike is allowed to roll the extra balls to complete the frame. However no more than three balls can be rolled in tenth frame.

9 LET S START THE DEMO

10 GENERAL MISUNDERSTANDINGS (IN COMPARISON TOO) but we saw in the previous lessons that this is not the intention of Meyer... it was the childhood approach is often viewed as using assertion or defensive programming, i.e., testing the contract at run-time When you write code the way, you get the code and its unit-tests at the same time

11 SOME COMMON POINTS the compiler help us to check for syntax & semantics of the language, and by type checking with syntax of the application. e try yo give an help in checking the semantics of the application It s all about specifying the desired behavior and using some sort of automation to check that the specification is being satisfied Both concepts want to improve software quality by providing a set of conceptual building blocks that allow you to prevent bugs before making them. DbC and are about code-based specification

12 DESIGN AS A SIDE EFFECT Moreover contracts lead to components with very few dependencies (promoting the SRP) since it s difficult to write contracts for components with many responsibilities. drives the API design as you go with your tests. [...] This kind of specification is functional and example-driven

13 AND TESTING

14 AND TESTING is not testing it is a design technique

15 AND TESTING is not testing it is a design technique is bad testing the common argument used to demonstrate it is to say that it does guarantee no coverage criteria

16 AND TESTING is not testing it is a design technique is bad testing the common argument used to demonstrate it is to say that it does guarantee no coverage criteria What kind of testing is? black-box or white-box?

17 WHAT IS EASIER? In my mind is more "inductive". You start with examples (test cases) and your code embodies the general solution to those examples. seems more "deductive", after gathering requirements you determine object behavior and contracts. You then code the specific implementation of those contracts. Writing contracts is somewhat difficult, more so than tests that are concrete examples of behavior, this may be part of the reason is more popular than. [ is easier to write and to maintain because no special test cases need to be specified, just conditions for method parameters, expected results and state invariant that must be preserved [

18 I think there is overlap between DbC and, however, I don't think there is duplicated work: introducing DbC will probably result in a reduction of test cases. Let me explain. In, tests aren't really tests. They are behavioral specifications. However, they are also design tools: by writing the test first, you use the external API of your object under test that you haven't actually written yet in the same way that a user would. That way, you design the API in a way that makes sense to a user, and not in the way that makes it easiest for you to implement. Something like queue.full? instead of queue.num_entries == queue.size. This second part cannot be replaced by Contracts. The first part can be partially replaced by contracts, at least for unit tests. tests serve as specifications of behavior, both to other developers (unit tests) and domain experts (acceptance tests). Contracts also specify behavior, to other developers, to domain experts, but also to the compiler and the runtime library. But contracts have fixed granularity: you have method pre- and postconditions, object invariants, module contracts and so on. Maybe loop variants and invariants. Unit tests however, test units of behavior. Those might be smaller than a method or consist of multiple methods. That's not something you can do with contracts. And for the "big picture" you still need integration tests, functional tests and acceptance tests. And there is another important part of that DbC doesn't cover: the middle D. In, tests drive your development process: you never write a single line of implementation code unless you have a failing test, you never write a single line of test code unless your tests all pass, you only write the minimal amount of implementation code to make the tests pass, you only write the minimal amount of test code to produce a failing test. In conclusion: use tests to design the "flow", the "feel" of the API. Use contracts to design the, well, contract of the API. Use tests to provide the "rhythm" for the development process. Something like this: 1. Write an acceptance test for a feature 2. Write a unit test for a unit that implements a part of that feature 3. Using the method signature you designed in step 2, write the method prototype 4. Add the postcondition 5. Add the precondition 6. Implement the method body 7. If the acceptance test passes, goto 1, otherwise goto 2 If you want to know what Bertrand Meyer, the inventor of Design by Contract, thinks about combining and DbC, there is a nice paper by his group, called Contract-Driven Design = Test-Driven Development - Writing Test Cases. The basic premise is that contracts provide an abstract representation of all possible cases, whereas test cases only test specific cases. Therefore, a suitable test harness can be automatically generated from the contracts.

19 HOW TO ADD CONTRACTS Contracts extend the definition of a code element, but how? language level (Eiffel) execution framework level (Code Contract in.net) library level annotation in java (c4j) aspect orientation (Contract4J)

20 The first big problem putting down this lesson has been that I did find no dilbert s comics on the argument... problems with real world contracts and in the software world so, this is not referring to design by contract, but with real world2 contracts, but I think that the metaphor could be used in both ways... so... the long time and effort due in understanding and writing a usefull and approved contract is a problem in dbc approach too

21 REFERENCES the two links that express better my ideas code-contracts/comparison-of-dbc-and-tdd-part-1 interesting exposition

22 PROBABLY INTERESTING READING... Contract Driven Development =Test Driven Development Writing Test Cases [

23

24

25

26

27 Design?

28 Design?

29 Design?

30

31

32

33 Formal verification?

34 Formal verification?

35 Formal verification?

36 Formal verification? Support for evolution of the software?

37 Formal verification? Support for evolution of the software?

38 Formal verification? Support for evolution of the software?

39 Formal verification? Support for evolution of the software? - short iteration, continuos integration?

40 Formal verification? Support for evolution of the software? - short iteration, continuos integration?

41 Formal verification? Support for evolution of the software? - short iteration, continuos integration?

42 Formal verification? Support for evolution of the software? - short iteration, continuos integration? - design for change?

43 Formal verification? Support for evolution of the software? - short iteration, continuos integration? - design for change?

44 Formal verification? Support for evolution of the software? - short iteration, continuos integration? - design for change?

45 Formal verification? Support for evolution of the software? - short iteration, continuos integration? - design for change? - inheritance?

46 Formal verification? Support for evolution of the software? - short iteration, continuos integration? - design for change? - inheritance?

47 Formal verification? Support for evolution of the software? - short iteration, continuos integration? - design for change? - inheritance?

48 Formal verification? Support for evolution of the software? - short iteration, continuos integration? - design for change? - inheritance? comunication towards developers

49 Formal verification? Support for evolution of the software? - short iteration, continuos integration? - design for change? - inheritance? comunication towards developers

50 Formal verification? Support for evolution of the software? - short iteration, continuos integration? - design for change? - inheritance? comunication towards developers

51 Formal verification? Support for evolution of the software? - short iteration, continuos integration? - design for change? - inheritance? comunication towards developers comunication towards compiler

52 Formal verification? Support for evolution of the software? - short iteration, continuos integration? - design for change? - inheritance? comunication towards developers comunication towards compiler

53 Formal verification? Support for evolution of the software? - short iteration, continuos integration? - design for change? - inheritance? comunication towards developers comunication towards compiler

54 Formal verification? Support for evolution of the software? - short iteration, continuos integration? - design for change? - inheritance? comunication towards developers comunication towards compiler

55 Formal verification? Support for evolution of the software? - short iteration, continuos integration? - design for change? - inheritance? comunication towards developers comunication towards compiler

56 Formal verification? Support for evolution of the software? - short iteration, continuos integration? - design for change? - inheritance? comunication towards developers comunication towards compiler

57 Formal verification? Support for evolution of the software? - short iteration, continuos integration? - design for change? - inheritance? comunication towards developers comunication towards compiler

58 Formal verification? Support for evolution of the software? - short iteration, continuos integration? - design for change? - inheritance? comunication towards developers comunication towards compiler

59 Formal verification? Support for evolution of the software? - short iteration, continuos integration? - design for change? - inheritance? comunication towards developers comunication towards compiler

60 Formal verification? Support for evolution of the software? - short iteration, continuos integration? - design for change? - inheritance? comunication towards developers comunication towards compiler

61 Formal verification? Support for evolution of the software? - short iteration, continuos integration? - design for change? - inheritance? comunication towards developers comunication towards compiler

62 Formal verification? Support for evolution of the software? - short iteration, continuos integration? - design for change? - inheritance? comunication towards developers comunication towards compiler

63 Formal verification? Support for evolution of the software? - short iteration, continuos integration? - design for change? - inheritance? comunication towards developers comunication towards compiler

64 Formal verification? Support for evolution of the software? - short iteration, continuos integration? - design for change? - inheritance? comunication towards developers comunication towards compiler

65 Formal verification? Support for evolution of the software? - short iteration, continuos integration? - design for change? - inheritance? comunication towards developers comunication towards compiler

66 TOGETHER? This is a common results for example in comparison different verification techniques. METTERE FIGURA TESTING, INSPECTION... Redundancy If there is no inclusion relation, it makes sense to use both.