1. 1 Komponentai, kurie turi būti patikrinti, yra objektų klasės, kurios realizuojamos kaip objektai. l Didesniems vienetams negu individuali funkcija “baltos dėžės” testavimas turi būti išplėstas. Nėra akivaizdžios viršūnės smulkinančiam integravimui ir testavim ui. Objektinis testavimas

2. 2 Testavimo lygiai l Testuoti operacijas susietas su objektais. l Testuoti objektų klases. l Testuoti bendradarbiaujančių objektų grupes. l Testuoti užbaigtą objektinę sistemą.

3. 3 Objektų klasių testavimas Pilnas klasės testavimas apima : testavimas visų operacijų susietų s u objektu, nustatymas ir apklausinėjimas visų objektų atributų, bandymas objektų visose galimose būsenose. l Paveldimumas sukelia daug sunkumų sukurti klasių testus, kadangi informacija, kuri turi būti testuojama, nėra lokalizuota.

4. 4 Meteorologinės stoties objekto sąsaja l Testiniai atvejai reikalingi visoms operacijoms. l Naudoti būvio modelį, kad identifikuoti testavimui būsenų perėjimus. l Testavimo sekų pavyzdžiai: Shutdown  Waiting  Shutdown Waiting  Calibrating  Testing  Transmitting  Waiting Waiting  Collecting  Waiting  Summarising  Transmitting  Waiting

5. 5 Objektų integravimas l Integravimo lygiai yra mažiau aiškūs objektiškai--orientuotose sistemose. Grupės ( Cluster) testavimas liečia bendradarbiaujančių objektų integravimą ir testavimą. l Grupių identifikavimui naudojamos žinios apie objektų operacijas ir sistemos savybes, kurios yra įdiegtos šiose grupėse.

6. 6 Objektų grupių testavimo metodai l Naudojamų atvejų arba scenarijaus testavimas: n testavimas yra pagrįstas vartotojo ryšiu su sistema, n turi pranašumą, kad taip testuojamos sistemos savybės kaip patyrusių vartotojų. l Gijų testavimas: n sistemos atsakymų į įvykius testavimas kaip veiksmų gijų apdorojimas. l Objektų bendravimo testavimas: n testų sekos objektų bendravimui, kuris nutrūksta, kai objekto operacijos neprašo paslaugų iš kitų objektų.

7. 7 Testavimas pagal scenarijų l Atpažįsta scenarijų iš naudojamų atvejų (use-cases) ir jų papildymų su bendravimo diagramomis, kurios parodo objektus, įtrauktus į scenarijų. l Aptarkime meteorologinės stoties scenarijų, kur ataskaita yra sugeneruota.

8. 8 Surinkti meteorologinius duomenis

9. 9 Meteorologinės stoties testavimas l Vykdomų metodų gijos CommsController:request  WeatherStation:report  WeatherData:summarise l Įvedimas ir išvedimas: n įvedamas prašymas reikalauja susietų žinių ir galinės ataskaitos išvedimo, n gali būti pratestuota sukurtais “žaliais” duomenimis ir įsitikinta, kad reziumuota tinkamai, n naudojami tie patys “žali” duomenys testuoti WeatherData objektus.

10. 10 What is Object-Oriented Programming? Do we really know what it is?

11. 11 Things you “hear” about OO: a grain ( grūdas) of truth in all but one l It’s a “new way” of looking at things l It’s a paradigm shift l You have methods instead of functions l you pass messages l If you’ve used the “procedural approach” than you can’t transition to OO l You use objects, whatever they are! l You use polymorphism, whatever that is!

12. 12 Let’s compare OO to the “old ways” l Previous approach stressed algorithms. l Usuall referred to as “procedure- oriented” approach l I like A. Riel’s term: “Action-Oriented” approach

13. 13 Action-Oriented Programming l Stresses “getting the algorithm correct” l uses “functional decomposition” l Has a “main” calling routine that choreographs the activity, calling functions to implement the application

14. 14 Object-Oriented Programming l Stresses the data l Decompose the data, together with the functions that operate on that data l Put the data and operations into a “class” l An instance of the “class” is an object l Each “object” maintains its own data and operations: must initialize and clean up! l Decentralize control

15. 15 Let’s consider an example l Let’s compare the worst-case action- oriented with the best-case object- oriented l Then, we’ll consider the case when the action-oriented goes right! l And, the object-oriented goes wrong!

16. 16 A typical action-oriented topology F1() F4() F3( F2() F5()

17. 17 Consider a change to the data, marked X F1() F4() F3( F2() F5() Functions f1() and f2() must be modified

18. 18 However, suppose you or another developer added f6() (and forgot you did it!) F1() F4() F3( F2() F5() F6()

19. 19 However, suppose you or another developer added f6() (and forgot you did it!) F1() F4() F3( F2() F5() You compile, link and exec and it doesn’t work! F6()

20. 20 How does the OO approach control this complexity D1D2 D1’s dataD2’s data f1() f2() f3() f4() f5() f6() call

21. 21 Decompose the data l Data is encapsulated in a class (or object) l well-defined public interface permits operations on the data

22. 22 When action-oriented goes right l Many people build systems using files, with each data structure in a separate file l the functions that operate on data are placed in the same file l some languages contain primitives to restrict operations within/across files (e.g. static, extern) l here, AO takes on attributes of OO approach

23. 23 How can OO go wrong l The god class: performs most of the work, leaves minor details to other classes l proliferation ( daugintis) of classes: too many classes for the size of the problem

24. 24 Class design heuristics l All data is hidden in a class l implement a minimum public interface that all classes understand l do not put implementation details in the public interface l A class should capture one, and only one, key abstraction l Keep related data and behavior in one place

25. 25 An important aspect of OO design is to determine the relationships between classes Polymorphos-multiform Substitutability- Įstatomumas

26. 26 Testing Object-Oriented Software An Overview, from McGregor/Sykes

27. 27 Advantages of OO Approach l improvement to development process & to code l if implemented correctly, oo software is higher quality than software developed under the procedural paradigm: understandability, maintainability, extensibility, reliability and reusability

28. 28 Adv of OO l represents design results as refinement & extension of analysis l represents implementation results as a refinement & extension of design l testing OO is based primarily in the requirements of the software

29. 29 What’s different about testing OO l Much carry-over from the procedural approach l For example, still do unit testing; however, what constitutes a until may be different in OO

30. 30 What is software? l instruction codes and data necessary to accomplish a task, as well as all representations of those instructions and data l what are representations: the models developed during analysis

31. 31 Adv of models l test cases can be identified earlier in the development process l errors and faults can be detected earlier l test cases developed for analysis models can be refined and extended to test design models, which can be refined and extended to test subsystems and systems

32. 32 The approach l analyze a little l design a little l code a little l test what you can

33. 33 Kinds of testing for OO l Model testing l interaction testing; replaces integration testing l system and subsystem testing l acceptance testing: testing of the application by end users, usually before release

34. 34 Testing Perspective l questions the validity of software & utilizes thorough investigation to identify failures l makes execution-based testing more powerful than reviews or inspections; l reviews never find something that’s missing -- only validates what’s there

35. 35 OO Programming centers around: l object l message l encapsulation l inheritance, and l polymorphism

36. 36 For testing, an object : l might be destroyed before it should be l might persist ( išsilaikyti) longer than it should l might be manipulated by another object so that its data becomes inconsistent with other data in the system l might have inappropriate data or exhibit incorrect behavior in the system

37. 37 For testing, a message can fail if: l a sender requests an operation not defined by the receiver l a message contains an improper actual parameter l the receiver cannot perform the requested operation at the time of the request l a sender doesn’t handle the reply properly l the receiver returns an incorrect reply

38. 38 Two parts to each class l specification: what each object in the class can do n query operations (in C++ s/b const) n modifier operations l implementation: how each object in the class does it

39. 39 Two special kinds of class operations l constructor l destructor l These are different from queries and modifiers: invoked implicitly!

40. 40 3 Kinds of statements to specify the semantics of a class l pre-conditions: conditions that must hold before an operation can be performed l post-conditions: conditions that must hold after the operation is performed l class invariants: conditions that must always hold for an instance of a class; an implied ( numatomas) post-condition for each operation; can be violated during execution

41. 41 methods l Characterized by behavior l behavior can be specified by: n state diagrams n sequence diagrams l Two approaches to defining the interface between sender and receiver: n contract approach, B. Meyers (1994) n defensive programming approach

42. 42 Contract Approach l The interface is defined in terms of the obligations of the sender and receiver involved in the action l obligations specified by pre/post conditions l pre-condition: describe the obligation of the sender (to ensure preconditions are met) l post-condition: obligations of the receiver (to ensure post-conditions and class invariants are met)

43. 43 #ifndef PUCKSUPPLY_H #define PUCKSUPPLY_H class PuckSupply { public: PuckSupply(); ~PuckSupply(); Puck * get(); int count() const; private: int _count; Puck* _store[N]; }; #endif #include “PuckSupply.h” PuckSupply::PuckSupply():(N) { for (int I = 0; I < N; ++I) { _store[I] = new Puck; }; } PuckSupply::~Puck() { (for int I=0; I < _count; ++I) { delete _store[I]; }; } Puck* PuckSupply::get() { return _count > 0 ? _store[--_count]:0; } int PuckSupply::count() const { return _count; }

44. 44 Spec for PuckSupply based on contracts A puck supply is a set of pucks not in play that can be retrieved one at a time. The pucks are created by a puck supply when it is created. l Class invariant: count associated w/ puck supply is always an integer from 0 to 3, incl. l The count() operation can be applied at any time; it returns the no. of pucks left in the receive and has no effect on the receiver l The get() operation can only be applied if the receiver has at least one puck (count > 0) l constructor has no pre-conditions. The result of the constructor is a puck supply of 3 (count = 3) l the destructor has no pre-conditions; the destructor deletes any pucks that remain in the object

45. 45 Spec for PuckSupply based on Defensive Programming A puck supply is a set of pucks not in play that can be retrieved one at a time. The pucks are created by a puck supply when it is created. l Class invariant: (count between 0 & 3) -- same l The count() operation: (returns no. of pucks) -- same l The get() operation can be applied at any time; if the receiver has at least one puck (count>0) then the result of the operation is a return of a pointer to a puck and reduce the number of pucks by one; owise a NULL pointer is returned and count attribute remains 0. l Constructor: (gives you 3 pucks) -- same l the destructor: (deletes remaining pucks) -- same

46. 46 Spec for PuckSupply based on Contract Programming Using OCL Notation PuckSupply count >= 0 PuckSupply::PuckSupply(): pre: -- none post:count = 3 AND pucks->forAll(puck | not puck.inPlay()) void PuckSupply::count() const: pre:-- none post:result = count Puck * PuckSupply::get() pre:count > 0 post: result = pucks->asSequence->first AND count = count@pre-1

47. 47 Defensive vs Contract l Defensive: n interface defined in terms of receiver n an operation typically uses return code, or exception n goal is to identify “garbage in” to eliminate “garbage out” n tends to increase software complexity because each sender must follow each message w/ check of return code (even though receiver already checked) n complicates class testing: must test for all possible outcomes! n Complicates interaction testing: all outcomes handled by sender

48. 48 Defensive vs Contract l Contract: n reflects mutual responsibility and trust n eliminates need for receiver to check return codes n important question: How are contracts enforced? n Simplifies class testing but complicates interaction testing: ensure sender meets pre-conditions

49. 49 A class implementation has: l Data members l set of member functions l set of constructors l destructor l set of private operations (in private interface)

50. 50 Class testing l Since a class is an abstraction of commonaltie, the process must ensure that a rep sample of instances of the class are selected for testing

51. 51 Potential causes of failure of class design/implementation l Doesn’t meet specification l contains operations and data that affects the proper construction of instances l might rely on collaboration w/ other objects l might meet its spec, but spec might be incorrect, or violate a higher requirement l might specify pre-conditions but not provide mechanism to check if pre-condition is met

52. 52 In contract/defensive approach: l Contract: must test to ascertain that every attempt to apply an operation must first satisfy pre-conditions l defensive: ascertain that every possible outcome is handled properly

53. 53 Inheritance l Define a new class based on definition of an existing class l used only to implement is-a-kind-of relationship l best use of inheritance is with respect to interfaces and not implementations

54. 54 Inheritance, from testing view l Permits bugs to be propagated from a class to its descendents ( palikuonis) l permits test case reuse l verify it’s used properly: n use of inheritance solely for code reuse will probably lead to maintenance difficulty, n this is a design issue, but so common that testers can make a significant contribution by making sure inheritance is used properly

55. 55 Polymorphism l A sender in an OO program can use an object based on its interface and not on its exact class l a derived class inherits the public interface of its base class and thus instances of either class can respond to the same messages l in Java, supported through inheritance or interfaces

56. 56 Poly (cont.) l Because polymorphic references hide the actual class of a referent, both C++ & Java provide support for determining at run time the actual class of a referent l Good OO design holds these run-time inspections to a minimum because they create a maintenance point: extension of the class hierarchy introduces more types to be inspected

57. 57 Testing polymorphism l An operation can return a reply that is a polymorphic reference; the actual class of the referent could be incorrect l any operation can have one or more parameters that is a polymorphic reference; the parameter could be incorrect l Number of instances to check could be large: Need statistical analysis to determine which configurations will expose most faults for least cost

58. 58 OO development products l Use cases l class diagrams l activity diagrams n state diagrams n sequence diagrams l class specification (in OCL) l state diagrams l activity diagrams