Testing and Mocking Object - The Art of Mocking.


Published on

The Art Of Mocking with EasyMock in Java.

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • 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.
  • Testing and Mocking Object - The Art of Mocking.

    1. 1. Testing Overview and Mocking Objects Deepak Singhvi Feb, 04 2009
    2. 2. Goal of Presentation <ul><li>Show how “Mocking Objects” can greatly improve unit testing by facilitating tests that are easier to write and less dependant upon objects outside the test domain </li></ul><ul><li>The ultimate goal - Quality </li></ul>
    3. 3. Agenda <ul><li>Software Quality </li></ul><ul><li>Testability and the problems in it </li></ul><ul><li>V model </li></ul><ul><li>Terminologies </li></ul><ul><ul><li>Error, Fault, Failure </li></ul></ul><ul><li>Test Methodologies </li></ul><ul><ul><li>Functional </li></ul></ul><ul><ul><li>Behavioral </li></ul></ul><ul><li>Type of testing </li></ul><ul><ul><li>UT, ST, IT, Alpha, Beta, etc </li></ul></ul><ul><li>Mocking Objects - Why </li></ul><ul><li>Mocking using EasyMock and examples </li></ul><ul><li>Q & A </li></ul>
    4. 4. Software Quality QUALITY Formal Technical Reviews Software Engineering Methods Standards and Procedures SQA Measurements Testing
    5. 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. ... 
    6. 6. Testability <ul><li>Testability has two facets: </li></ul><ul><ul><li>controllability and </li></ul></ul><ul><ul><li>observability. </li></ul></ul><ul><li>To test a component we must be able to: </li></ul><ul><ul><li>control the input (and internal state) and </li></ul></ul><ul><ul><li>observe its outputs . </li></ul></ul><ul><li>However, there are many obstacles to controllability and observability: </li></ul><ul><ul><li>A component under test is almost always embedded in another system. </li></ul></ul><ul><ul><li>A component is embedded in another system and we wants to test that another system. </li></ul></ul>
    7. 7. Why to do testing <ul><li>Tests Keep you out of the (time hungry) debugger! </li></ul><ul><li>Tests Reduce Bugs in New Features </li></ul><ul><li>Tests Reduce Bugs in Existing Features </li></ul><ul><li>Tests Reduce the Cost of Change </li></ul><ul><li>Tests Improve Design </li></ul><ul><li>Tests Allow Refactoring </li></ul><ul><li>Tests Constrain Features </li></ul><ul><li>Testing Is Fun </li></ul><ul><li>Testing Forces You to Slow Down and Think </li></ul><ul><li>Testing Makes Development Faster </li></ul><ul><li>Tests Reduce Fear </li></ul>
    8. 8. Who Tests the Software? developer independent tester Understands the system but, will test &quot;gently&quot; and, is driven by &quot;delivery&quot; Must learn about the system, but, will attempt to break it and, is driven by quality
    9. 9. The V-model of development
    10. 10. Terminology <ul><li>Error </li></ul><ul><ul><li>Represents mistakes made by people </li></ul></ul><ul><li>Fault </li></ul><ul><ul><li>Is result of error. May be categorized as </li></ul></ul><ul><ul><ul><li>Fault of Commission – we enter something into representation that is incorrect </li></ul></ul></ul><ul><ul><ul><li>Fault of Omission – Designer can make error of omission, the resulting fault is that something is missing that should have been present in the representation </li></ul></ul></ul><ul><li>Failure </li></ul><ul><ul><li>Occurs when fault executes. </li></ul></ul><ul><li>Incident </li></ul><ul><ul><li>Behavior of fault. An incident is the symptom(s) associated with a failure that alerts user to the occurrence of a failure </li></ul></ul><ul><li>Test case </li></ul><ul><ul><li>Associated with program behavior. It carries set of input and list of expected output </li></ul></ul><ul><li>Verification </li></ul><ul><ul><li>Process of determining whether output of one phase of development conforms to its previous phase. </li></ul></ul><ul><li>Validation </li></ul><ul><ul><li>Process of determining whether a fully developed system conforms to its SRS document </li></ul></ul>
    11. 11. A Testing Life Cycle Requirement Specs Design Coding Testing Fault Resolution Fault Isolation Fault Classification Error Fault Fault Fault Error Error incident Fix
    12. 12. Classification of Test <ul><li>There are two levels of classification </li></ul><ul><ul><li>One distinguishes at granularity level </li></ul></ul><ul><ul><ul><li>Unit level </li></ul></ul></ul><ul><ul><ul><li>System level </li></ul></ul></ul><ul><ul><ul><li>Integration level </li></ul></ul></ul><ul><ul><li>Other classification is based on methodologies </li></ul></ul><ul><ul><ul><li>Black box (Functional) Testing </li></ul></ul></ul><ul><ul><ul><li>White box (Structural) Testing </li></ul></ul></ul><ul><ul><ul><li>Black-box and white-box are test design methods. </li></ul></ul></ul><ul><ul><ul><li>Black-box test design treats the system as a &quot;black-box&quot;, so it doesn't explicitly </li></ul></ul></ul><ul><ul><ul><li>use knowledge of the internal structure. Black-box test design is usually </li></ul></ul></ul><ul><ul><ul><li>described as focusing on testing functional requirements. Synonyms for black- </li></ul></ul></ul><ul><ul><ul><li>box include: behavioral, functional, opaque-box, and closed-box. </li></ul></ul></ul><ul><ul><ul><li>White-box test design allows one to peek inside the &quot;box&quot;, and it focuses </li></ul></ul></ul><ul><ul><ul><li>specifically on using internal knowledge of the software to guide the selection of </li></ul></ul></ul><ul><ul><ul><li>test data. Synonyms for white-box include: structural, glass-box and clear-box. </li></ul></ul></ul>
    13. 13. Relationship – program behaviors Program Behaviors Specified (expected) Behavior Programmed (observed) Behavior Fault Of Omission Fault Of Commission Correct portion
    14. 14. Test methodologies <ul><li>Functional (Black box) inspects specified behavior </li></ul><ul><ul><li>Equivalence partitioning </li></ul></ul><ul><ul><li>Boundary analysis </li></ul></ul><ul><ul><li>Error guessing </li></ul></ul><ul><li>Structural (White box) inspects programmed behavior </li></ul><ul><ul><li>Statement coverage </li></ul></ul><ul><ul><li>Decision coverage </li></ul></ul><ul><ul><li>Condition coverage </li></ul></ul><ul><ul><li>Decision/condition coverage </li></ul></ul><ul><ul><li>Multiple condition coverage </li></ul></ul>
    15. 15. When to use what <ul><li>Few set of guidelines available </li></ul><ul><li>A logical approach could be </li></ul><ul><ul><li>Prepare functional test cases as part of specification. However they could be used only after unit and/or system is available. </li></ul></ul><ul><ul><li>Preparation of Structural test cases could be part of implementation/code phase. </li></ul></ul><ul><ul><li>Unit, Integration and System testing are performed in order. </li></ul></ul>
    16. 16. More types of Testing <ul><li>Unit Testing : The most 'micro' scale of testing; to test particular functions or code modules. Typically done by the programmer and not by testers, as it requires detailed knowledge of the internal program design and code. Not always easily done unless the application has a well-designed architecture with tight code; may require developing test driver modules or test harnesses. Integration Testing - testing of combined parts of an application to determine if they function together correctly. The 'parts' can be code modules, individual applications, client and server applications on a network, etc. This type of testing is especially relevant to client/server and distributed systems. Functional Testing : Black-box type testing geared to functional requirements of an application; this type of testing should be done by testers. System Testing : Black-box type testing that is based on overall requirements specifications; covers all combined parts of a system. Sanity Testing : Typically an initial testing effort to determine if a new software version is performing well enough to accept it for a major testing effort. For example, if the new software is crashing systems every 5 minutes, bogging down systems to a crawl, or destroying databases, the software may not be in a 'sane' enough condition to warrant further testing in its current state. </li></ul>
    17. 17. Still more types of testing <ul><li>Performance Testing : This term is often used interchangeably with 'stress' and 'load' testing. Ideally 'performance' testing (and any other 'type' of testing) is defined in requirements documentation or QA or Test Plans. Usability Testing : Testing for 'user-friendliness'. Clearly this is subjective, and will depend on the targeted end-user or customer. User interviews, surveys, video recording of user sessions, and other techniques can be used. Programmers and testers are usually not appropriate as usability testers. Installation/Uninstallation Testing : Testing of full, partial, or upgrade install/uninstall processes. Security Testing : Testing how well the system protects against unauthorized internal or external access, willful damage, etc; may require sophisticated testing techniques. Compatability Testing : Testing how well software performs in a particular hardware/software/operating system/network/etc. environment. Ad-hoc Testing : Testing the application in a random manner. Alpha Testing : Testing of an application when development is nearing completion; minor design changes may still be made as a result of such testing. Typically done by end-users or others, not by programmers or testers. Beta Testing : Testing when development and testing are essentially completed and final bugs and problems need to be found before final release. Typically done by end-users or others, not by programmers or testers. </li></ul>
    18. 18. Testing Walkthroughs Code Reviews Static Dynamic Inspections White Box Black Box Unit Testing
    19. 19. Black Box System Testing Integration Testing UAT Testing Alpha Testing Beta Testing Functional Testing Usability Testing Non Functional Testing Performance Testing
    20. 20. Functional Testing System Testing Smoke Testing Regression Testing Sanity Testing Adhoc Testing Retesting Gorilla Testing Negative Testing
    21. 21. Non Functional Testing System Testing Load Testing Volume Testing Stress testing Performance Testing
    22. 22. Testing Steps
    23. 23. Art of Mocking Objects
    24. 24. What are the Problems of Software Testing? <ul><li>Time is limited </li></ul><ul><li>Applications are complex </li></ul><ul><li>Requirements are fluid </li></ul>
    25. 25. Few Definitions <ul><li>Test Fixture/ Test Class – A class with some unit tests in it. </li></ul><ul><li>Test (or Test Method) – a test implemented in a Test Fixture </li></ul><ul><li>Test Suite - A set of test grouped together </li></ul><ul><li>Test Harness/ Runner – The tool that actually executes the tests. </li></ul>
    26. 26. Mock Objects <ul><li>The objective of unit testing is to exercise just one method at a time. </li></ul><ul><li>But what happens when the method depends on other hard-to-control elements, such as: </li></ul><ul><ul><li>network or </li></ul></ul><ul><ul><li>database </li></ul></ul><ul><li>Method Controllability is threatened by these hard- to-control elements. </li></ul>
    27. 27. Why engage in Object Mocking? <ul><li>The real object has behavior that is hard to cause or is non-deterministic </li></ul><ul><li>The real object is difficult to set up </li></ul><ul><li>The real object is slow </li></ul><ul><li>The real object has (or is ) a UI </li></ul><ul><li>Test needs to query the object but queries are not available </li></ul><ul><li>Real objects do not exist </li></ul>
    28. 28. Mock Objects - Definition <ul><li>Using mock objects we can get around these problemes. </li></ul><ul><li>A mock Object is a Test Pattern which proposes a fake implementation of objects hard to control. </li></ul><ul><li>Its purpose is to simulate the real objects strictly for testing. </li></ul><ul><li>They have the same interface of the real objects. </li></ul>
    29. 29. The importance of IoC <ul><li>Inversion of Control (aka DIP – Dependency Inversion Prinicipal) </li></ul><ul><ul><li>A. High-level modules should not depend on low-level modules. Both should depend on abstractions. </li></ul></ul><ul><ul><li>B. Abstractions should not depend on details. Details should depend on abstractions. </li></ul></ul>OOD principle
    30. 30. Inversion Of Control <ul><li>Inversion Of Control, Dependency Injection, The Hollywood Principal etc. </li></ul><ul><li>In stead of instantiating concrete class references in your class, depend on an abstraction and allow your concrete dependencies to be given to you. </li></ul>OOD principle
    31. 31. Concrete Class Dependency
    32. 32. Allow dependency to be passed in
    33. 33. Some mock principals to follow <ul><li>Mocking Interfaces and Classes outside Your Code </li></ul><ul><ul><li>In general – do not mock code you do not own. For example – do not mock Active Directory or LDAP ( Lightweight Directory Access Protocol ), in stead - create your own interface to wrap the interaction with the external API classes. Like: </li></ul></ul>
    34. 34. Rules of thumb <ul><li>If you cannot test code – change it so you can. </li></ul><ul><li>Test first! </li></ul><ul><li>Only ONE concrete class per test – MOCK THE REST. </li></ul>
    35. 35. How many mocks???? <ul><li>How Many Mock Objects in any Given Test? </li></ul><ul><li>There should never be more than 2-3 mock objects involved in any single unit test.  I wouldn’t make a hard and fast rule on the limit, but anything more than 2 or 3 should probably make you question the design.  The class being tested may have too many responsibilities or the method might be too large.  Look for ways to move some of the responsibilities to a new class or method.  Excessive mock calls can often be a sign of poor encapsulation.  </li></ul><ul><li>Only Mock your Nearest Neighbor </li></ul><ul><li>Ideally you only want to mock the dependencies of the class being tested, not the dependencies of the dependencies.  From hurtful experience, deviating from this practice will create unit test code that is very tightly coupled to the internal implementation of a class’s dependencies.  </li></ul>
    36. 36. The law of Demeter (LoD) <ul><li>The Law of Demeter (LoD) is a simple style rule for designing object-oriented systems. &quot;Only talk to your friends&quot; is the motto. </li></ul><ul><li>Each unit should only use a limited set of other units: only units “closely” related to the current unit. </li></ul><ul><li>“ Each unit should only talk to its friends.” “Don’t talk to strangers.” </li></ul><ul><li>Main Motivation: Control information overload. We can only keep a limited set of items in short-term memory. </li></ul><ul><li>Too many mocks and mocking past your immediate neighbors are due to violating this prinicpal. </li></ul>
    37. 37. Law of Demeter FRIENDS
    38. 38. “closely related”
    39. 39. Violations: Dataflow Diagram A B C 1:b 2:c P Q 3:p() 4:q() foo() bar() m
    40. 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. 41. Testing is easy in isolation
    42. 42. Testing is harder with dependencies …
    43. 43. … so remove the dependencies (for developer testing)
    44. 44. Examples <ul><li>To get a Mock Object, we need to </li></ul><ul><li>1) Create a Mock Object for the interface we would like to simulate, </li></ul><ul><li>2) Record the expected behavior, </li></ul><ul><li>3) And switch the Mock Object to replay state. </li></ul><ul><li>EasyMock uses a record/replay metaphor for setting expectations. For each object you wish to mock you create a mock object. To indicate an expectation you call the method, with the arguments you expect on the mock. Once you've finished setting expectations you call replay - at which point the mock finishes the recording and is ready to respond to the primary object. Once done you call verify. </li></ul>
    45. 45. <ul><li>testRemoveNonExistingDocument : </li></ul><ul><ul><li>After activation in step 3, mock is a Mock Object for the Collaborator interface that expects no calls. This means that if we change our ClassUnderTest to call any of the interface's methods, the Mock Object will throw an AssertionError: </li></ul></ul><ul><li>Verifying Behavior :There is one error that we have not handled so far: If we specify behavior, we would like to verify that it is actually used. The current test would pass if no method on the Mock Object is called. To verify that the specified behavior has been used, we have to call verify(mock): </li></ul>
    46. 46. Expecting an Explicit Number of Calls <ul><li>Up to now, our test has only considered a single method call. The next test should check whether the addition of an already existing document leads to a call to mock.documentChanged() with the appropriate argument. To be sure, we check this three times </li></ul><ul><li>To avoid the repetition of mock.documentChanged(&quot;Document&quot;), EasyMock provides a shortcut. We may specify the call count with the method times(int times) on the object returned by expectLastCall(). The code then looks like: expectLastCall().times(3); </li></ul>
    47. 47. Specifying Return Values <ul><li>For specifying return values, we wrap the expected call in expect(T value) and specify the return value with the method andReturn(Object returnValue) on the object returned by expect(T value). </li></ul><ul><li>As an example, we check the workflow for document removal. If ClassUnderTest gets a call for document removal, it asks all collaborators for their vote for removal with calls to byte voteForRemoval(String title) value. Positive return values are a vote for removal. If the sum of all values is positive, the document is removed and documentRemoved(String title) is called on all collaborators: </li></ul>
    48. 48. Relaxing Call Counts <ul><li>To relax the expected call counts, there are additional methods that may be used instead of times(int count): </li></ul><ul><li>times(int min, int max) </li></ul><ul><ul><li>to expect between min and max calls, </li></ul></ul><ul><li>atLeastOnce() </li></ul><ul><ul><li>to expect at least one call, and </li></ul></ul><ul><li>anyTimes() </li></ul><ul><ul><li>to expected an unrestricted number of calls. </li></ul></ul><ul><li>If no call count is specified, one call is expected. If we would like to state this explicitely, once() or times(1) may be used. </li></ul>
    49. 49. Flexible Expectations with Argument Matchers <ul><li>If you would like to use matchers in a call, you have to specify matchers for all arguments of the method call. </li></ul><ul><li>There are a couple of predefined argument matchers available. </li></ul><ul><li>eq(X value) </li></ul><ul><ul><li>Matches if the actual value is equals the expected value. Available for all primitive types and for objects. </li></ul></ul><ul><li>anyBoolean(), anyByte(), anyChar(), anyDouble(), anyFloat(), anyInt(), anyLong(), anyObject(), anyShort() </li></ul><ul><ul><li>Matches any value. Available for all primitive types and for objects. </li></ul></ul><ul><li>eq(X value, X delta) </li></ul><ul><ul><li>Matches if the actual value is equal to the given value allowing the given delta. Available for float and double. </li></ul></ul><ul><li>aryEq(X value) </li></ul><ul><ul><li>Matches if the actual value is equal to the given value according to Arrays.equals(). Available for primitive and object arrays. </li></ul></ul><ul><li>isNull() </li></ul><ul><ul><li>Matches if the actual value is null. Available for objects. </li></ul></ul><ul><li>notNull() </li></ul><ul><ul><li>Matches if the actual value is not null. Available for objects. </li></ul></ul><ul><li>same(X value) </li></ul><ul><ul><li>Matches if the actual value is the same as the given value. Available for objects. </li></ul></ul>
    50. 50. Machers contd. <ul><li>isA(Class clazz) </li></ul><ul><ul><li>Matches if the actual value is an instance of the given class, or if it is in instance of a class that extends or implements the given class. Null always return false. Available for objects. </li></ul></ul><ul><li>lt(X value), leq(X value), geq(X value), gt(X value) </li></ul><ul><ul><li>Matches if the actual value is less/less or equal/greater or equal/greater than the given value. Available for all numeric primitive types and Comparable. </li></ul></ul><ul><li>startsWith(String prefix), contains(String substring), endsWith(String suffix) </li></ul><ul><ul><li>Matches if the actual value starts with/contains/ends with the given value. Available for Strings. </li></ul></ul><ul><li>matches(String regex), find(String regex) </li></ul><ul><ul><li>Matches if the actual value/a substring of the actual value matches the given regular expression. Available for Strings. </li></ul></ul><ul><li>and(X first, X second) </li></ul><ul><ul><li>Matches if the matchers used in first and second both match. Available for all primitive types and for objects. </li></ul></ul><ul><li>or(X first, X second) </li></ul><ul><ul><li>Matches if one of the matchers used in first and second match. Available for all primitive types and for objects. </li></ul></ul><ul><li>not(X value) </li></ul><ul><ul><li>Matches if the matcher used in value does not match. </li></ul></ul><ul><li>cmpEq(X value) </li></ul><ul><ul><li>Matches if the actual value is equals according to Comparable.compareTo(X o). Available for all numeric primitive types and Comparable. </li></ul></ul><ul><li>cmp(X value, Comparator<X> comparator, LogicalOperator operator) </li></ul><ul><ul><li>Matches if comparator.compare(actual, value) operator 0 where the operator is <,<=,>,>= or ==. Available for objects. </li></ul></ul><ul><li>capture(Capture<T> capture) </li></ul><ul><ul><li>Matches any value but captures it in the Capture parameter for later access. You can do and(someMatcher(...), capture(c)) to capture a parameter from a specific call to the method. </li></ul></ul>
    51. 51. Limitations of Mocks <ul><li>Can only mock interfaces and virtual members (generally) </li></ul>
    52. 52. Why not JMock <ul><li>Too Stringy – Intelli-J, Eclipse does not like to refactor strings. </li></ul>
    53. 53. Why not NMock <ul><li>Same thing – stringy!!! </li></ul>
    54. 54. Mocks to use <ul><li>Rhino.Mocks (.net) </li></ul><ul><ul><li>http://www.ayende.com/projects/rhino-mocks.aspx </li></ul></ul><ul><li>EasyMock (java) </li></ul><ul><ul><li>http://www.easymock.org/ </li></ul></ul><ul><ul><li>NOT STRINGY!!! </li></ul></ul>
    55. 55. Thank You [email_address]
    56. 56. Object oriented design principle <ul><li>There are five principles of class design. </li></ul><ul><li>* (SRP) The SingleResponsibilityPrinciple </li></ul><ul><li>* (OCP) The OpenClosedPrinciple </li></ul><ul><li>* (LSP) The LiskovSubstitutionPrinciple </li></ul><ul><li>* (DIP) The DependencyInversionPrinciple </li></ul><ul><li>* (ISP) The InterfaceSegregationPrinciple </li></ul><ul><li>There are three principles of package cohesion </li></ul><ul><li>* (REP) The ReuseReleaseEquivalencePrinciple </li></ul><ul><li>* (CCP) The CommonClosurePrinciple </li></ul><ul><li>* (CRP) The CommonReusePrinciple </li></ul><ul><li>There are three principles of package coupling </li></ul><ul><li>* (ADP) The AcyclicDependenciesPrinciple </li></ul><ul><li>* (SDP) The StableDependenciesPrinciple </li></ul><ul><li>* (SAP) The StableAbstractionsPrinciple </li></ul>Back