EasyMock
  1. EasyMock
  2. EASYMOCK-111

Calling behaviour more than expected number of times does not assert failure when the call is from multple threads

    Details

    • Type: Bug Bug
    • Status: Open Open
    • Priority: Critical Critical
    • Resolution: Unresolved
    • Affects Version/s: 3.0, 3.1
    • Fix Version/s: None
    • Component/s: Core
    • Labels:
      None
    • Environment:
      maven and eclipse on windows.
    • Number of attachments :
      2

      Description

      If i expect a method on a mock to be called once, but call it twice from two different threads (once per thread), easymock does not fail the tests.

      If i start two threads, but make two calls from one of them ( uncomment line 97 of ExpirationServiceImpl ) it correctly fails the test.

      To demonstrate, untar and 'mvn test' the attached project.

      carteda@foobar:/c/dev/workspaces/two/fitp-aggregator/expirationservice$ mvn clean test

      [...]

      -------------------------------------------------------
      T E S T S
      -------------------------------------------------------
      Running com.nomura.fitp.expirationservice.ExpirationServiceTest
      Exception in thread "Thread-1" java.lang.AssertionError:
      Unexpected method call ExpirationHandler.handleExpiration(ExpirableTrade [expireTime=1328117827669, tradeId=already expired, tradeVersion=1, originalExpireTime=1328117857800]):
      ExpirationHandler.handleExpiration(ExpirableTrade [expireTime=1328117827669, tradeId=already expired, tradeVersion=1, originalExpireTime=0]): expected: 1, actual: 2
      ExpirationHandler.handleExpiration(ExpirableTrade [expireTime=1328117828269, tradeId=soon expired, tradeVersion=1, originalExpireTime=0]): expected: 1, actual: 0
      at org.easymock.internal.MockInvocationHandler.invoke(MockInvocationHandler.java:44)
      at org.easymock.internal.ObjectMethodsFilter.invoke(ObjectMethodsFilter.java:85)
      at $Proxy6.handleExpiration(Unknown Source)
      at com.nomura.fitp.expirationservice.internal.ExpirationServiceImpl$Retrier.run(ExpirationServiceImpl.java:120)
      at java.lang.Thread.run(Thread.java:662)
      Tests run: 4, Failures: 0, Errors: 0, Skipped: 3, Time elapsed: 0.579 sec

      Results :

      Tests run: 4, Failures: 0, Errors: 0, Skipped: 3

      [INFO] ------------------------------------------------------------------------
      [INFO] BUILD SUCCESS
      [INFO] ------------------------------------------------------------------------

      1. EASYMOCK-111.diff
        2 kB
        Paul Rashidi
      2. expirationservice.tbz
        16 kB
        daniel carter

        Activity

        Hide
        daniel carter added a comment -

        please ignore the .tbz attachment extension, i used the wrong switch, it's gzip compressesed .tgz

        tar xvfz expirationservice.tbz to extract

        Thanks,
        Dan.

        Show
        daniel carter added a comment - please ignore the .tbz attachment extension, i used the wrong switch, it's gzip compressesed .tgz tar xvfz expirationservice.tbz to extract Thanks, Dan.
        Hide
        Paul Rashidi added a comment -

        I wrote a simple additional test for EasyMock to show that async invocations still appear to work. @Daniel, might you want to increase your Thread.sleep to ensure you're not verifying before the invocation has happened?

        Show
        Paul Rashidi added a comment - I wrote a simple additional test for EasyMock to show that async invocations still appear to work. @Daniel, might you want to increase your Thread.sleep to ensure you're not verifying before the invocation has happened?
        Paul Rashidi made changes -
        Field Original Value New Value
        Attachment EASYMOCK-111.diff [ 59444 ]
        Alistair Todd made changes -
        Assignee Henri Tremblay [ henri ] Alistair Todd [ todderz ]
        Alistair Todd made changes -
        Assignee Alistair Todd [ todderz ] Henri Tremblay [ henri ]
        Hide
        Heiko Böttger added a comment -

        Just hit this bug. The problem most likely is that verify() only checks for expected call that where missing during test execution. If a call is not expected or called more than the maximum number the exception is thrown inside calling the thread. As an easy solution verify() should check if there was an unexcepted call and fail.

        Show
        Heiko Böttger added a comment - Just hit this bug. The problem most likely is that verify() only checks for expected call that where missing during test execution. If a call is not expected or called more than the maximum number the exception is thrown inside calling the thread. As an easy solution verify() should check if there was an unexcepted call and fail.

          People

          • Assignee:
            Henri Tremblay
            Reporter:
            daniel carter
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated: