Testing and Mocking Object - The Art of Mocking.
•Transferir como PPT, PDF•
2 gostaram•2,611 visualizações
The Art Of Mocking with EasyMock in Java.
![Goal of Presentation ,[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Semelhante a Testing and Mocking Object - The Art of Mocking.
Semelhante a Testing and Mocking Object - The Art of Mocking. (20)
Último
Último (20)
Testing and Mocking Object - The Art of Mocking.
- 1. Testing Overview and Mocking Objects Deepak Singhvi Feb, 04 2009
- 4. Software Quality QUALITY Formal Technical Reviews Software Engineering Methods Standards and Procedures SQA Measurements Testing
- 5. Testability IEEE 610.12 Testability. (1) Degree to which a system or component facilitates the establishment of a test criteria and the performance of tests to determine whether those criteria have been met. ...
- 8. Who Tests the Software? developer independent tester Understands the system but, will test "gently" and, is driven by "delivery" Must learn about the system, but, will attempt to break it and, is driven by quality
- 9. The V-model of development
- 11. A Testing Life Cycle Requirement Specs Design Coding Testing Fault Resolution Fault Isolation Fault Classification Error Fault Fault Fault Error Error incident Fix
- 13. Relationship – program behaviors Program Behaviors Specified (expected) Behavior Programmed (observed) Behavior Fault Of Omission Fault Of Commission Correct portion
- 18. Testing Walkthroughs Code Reviews Static Dynamic Inspections White Box Black Box Unit Testing
- 19. Black Box System Testing Integration Testing UAT Testing Alpha Testing Beta Testing Functional Testing Usability Testing Non Functional Testing Performance Testing
- 20. Functional Testing System Testing Smoke Testing Regression Testing Sanity Testing Adhoc Testing Retesting Gorilla Testing Negative Testing
- 21. Non Functional Testing System Testing Load Testing Volume Testing Stress testing Performance Testing
- 22. Testing Steps
- 23. Art of Mocking Objects
- 32. Allow dependency to be passed in
- 37. Law of Demeter FRIENDS
- 39. Violations: Dataflow Diagram A B C 1:b 2:c P Q 3:p() 4:q() foo() bar() m
- 40. OO Following of LoD A B C 1:b c P Q 3:p() q() foo() bar() m 2:foo2() 4:bar2() foo2 bar2
- 41. Testing is easy in isolation
- 42. Testing is harder with dependencies …
- 43. … so remove the dependencies (for developer testing)
Notas do Editor
- Equivalence Partitioning: In this method the input domain data is divided into different equivalence data classes. This method is typically used to reduce the total number of test case s to a finite set of testable test cases, still covering maximum requirements. Boundary Analysis: More application errors occur at the boundaries of input domain. ‘Boundary value analysis’ testing technique is used to identify errors at boundaries rather than finding those exist in center of input domain. Error guessing: Error Guessing comes with experience with the technology and the project. Error Guessing is the art of guessing where errors can be hidden. There are no specific tools and techniques for this, but you can write test cases depending on the situation: Either when reading the functional documents or when you are testing and find an error that you have not documented. Statement Coverage: Code coverage with the help test method execution ( tools like Emma, Clover), This metric reports whether each executable statement is encountered. Decision Coverage: This metric reports whether boolean expressions tested in control structures (such as the if-statement and while-statement) evaluated to both true and false. The entire boolean expression is considered one true-or-false predicate regardless of whether it contains logical-and or logical-or operators. Additionally, this metric includes coverage of switch-statement cases, exception handlers, and interrupt handlers. Condition Coverage: Condition coverage reports the true or false outcome of each boolean sub-expression, separated by logical-and and logical-or if they occur. Condition coverage measures the sub-expressions independently of each other. This metric is similar to decision coverage but has better sensitivity to the control flow. Decision/Condition Coverage: Condition/Decision Coverage is a hybrid metric composed by the union of condition coverage and decision coverage . Condition/decision coverage is a structural coverage criterion requiring that each condition within a decision is shown by execution to independently and correctly affect the outcome of the decision. Multiple Condition Coverage: Multiple condition coverage reports whether every possible combination of boolean sub-expressions occurs. As with condition coverage , the sub-expressions are separated by logical-and and logical-or, when present. The test cases required for full multiple condition coverage of a condition are given by the logical operator truth table for the condition.
- Why engage in Object Mocking? The real object has behaviour that is hard to cause or is non-deterministic. For example you need to make sure the object you are testing handles an exception thrown from a method invoked on another object. Sometimes it is impossible to force the exception to be thrown on the real object, but an exception can be easily thrown from a mock object. The real object is difficult to set up. Often you must manage the state of an object before using it in a test. This can be difficult if not impossible accomplish. Mock objects can make it much easier to setup state especially when testing objects that need to work with a database or network. The real object has (or is) a User Interface. Interaction with a GUI can be especially troublesome without resorting to using something like the java.awt.Robot class. Interacting with a mock object however can be much simpler. Test needs to query the object, but queries are not available. For example you need to determine if a “callback” method was invoked. Since the mock object verifies that each method was invoked as specified we can know that the “callback” was invoked. If you are engaging in Test-First development the real object may not exist. Using a mock object can aid in interface discovery, a mock object serves as a hypothesis of how an object should act.
- // Dependency Inversion Principle - Bad example class Worker { public void work() { // ....working } } class Manager { Worker m_worker; public void setWorker(Worker w) { m_worker=w; } public void manage() { m_worker.work(); } } class SuperWorker { public void work() { //.... working much more } } // Dependency Inversion Principle - Good example interface IWorker { public void work(); } class Worker implements IWorker{ public void work() { // ....working } } class SuperWorker implements IWorker{ public void work() { //.... working much more } } class Manager { IWorker m_worker; public void setWorker(IWorker w) { m_worker=w; } public void manage() { m_worker.work(); } }
- So, do not do new A().b.method1() in your class X, just delegate the responsibility to b to call . Just new A().callMethod1OfB() is enough and in callMethod1OFB() use B object and call the method1().
- The SingleResponsibilityPrinciple: In object-oriented programming , the single responsibility principle states that every object should have a single responsibility, and that all its services should be narrowly aligned with that responsibility. The Open Closed Principle: In object-oriented programming , the open/closed principle states " software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification "; [1] that is, such an entity can allow its behaviour to be modified without altering its source code . The LiskovSubstitutionPrinciple : Liskov's notion of "subtype" is based on the notion of substitutability; that is, if S is a subtype of T, then objects of type T in a program may be replaced with objects of type S without altering any of the desirable properties of that program The Dependency Inversion Principle (DIP) is sometimes regarded as a synonym for inversion of control . High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions. The Interface Segregation Principle: The dependency of one class to another one should depend on the smallest possible interface.