In a ScalaTest Suite, the expect method defined in Assertions, and inherited by Suite, interferes with the expect method if imported from EasyMock. You can invoke it by qualifying it, i.e., EasyMock.expect, or by changing its name on import, like this:

   import org.easymock.EasyMock.{expect => easyMockExpect, _}
   

But if you mix in this trait, you can just invoke call instead.

You can use this method, for example, to chain expectations like this:

   expecting {
     call(mock.getName).andReturn("Ben Franklin")
   }
   

Note: the name of this methods is call, not expectCall because "expect" appears in the surrounding expecting clause provided by this trait.

Moreover, because this method is marked implicit, you will usually be able to simply leave it off. So long as the result of the method call you are expecting doesn't have a method that satisfies the subsequent invocation (such as andReturn in this example), the Scala compiler will invoke call for you implicitly. Here's how that looks:

   expecting {
     mock.getName.andReturn("Ben Franklin")
   }
   

This method is provided simply to allow you to avoid repeating "expect" inside an expecting clause. Here's an example that uses the expectLastCall directly to express the expectation that the getName method will be invoked three times on a mock, each time returning "Ben Franklin":

   expecting {
     mock.getName.andReturn("Ben Franklin")
     expectLastCall.times(3)
   }
   

Using this method, you can compress this to:

   expecting {
     mock.getName.andReturn("Ben Franklin")
     lastCall.times(3)
   }
   

Using the EasyMock API directly, you create a mock with:

   val mockCollaborator = createMock(classOf[Collaborator])
   

Using this method, you can shorten that to:

   val mockCollaborator = mock[Collaborator]
   

Using the EasyMock API directly, you create a strict mock with:

   val mockCollaborator = createStrictMock(classOf[Collaborator])
   

Using this trait, you can shorten that to:

   val mockCollaborator = strictMock[Collaborator]
   

Using the EasyMock API directly, you create a nice mock with:

   val mockCollaborator = createNiceMock(classOf[Collaborator])
   

Using this trait, you can shorten that to:

   val mockCollaborator = niceMock[Collaborator]
   

Using the EasyMock API directly, you set expectations on a mock object with syntax like:

   mockCollaborator.documentAdded("Document")
   mockCollaborator.documentChanged("Document")
   expectLastCall().times(3)
   

This expecting method can make it more obvious which portion of your test code is devoted to setting expectations on mock objects. For example:

   expecting {
     mockCollaborator.documentAdded("Document")
     mockCollaborator.documentChanged("Document")
     lastCall.times(3)
   }
   

Using an expecting clause is optional, because it does nothing besides visually indicate which statements are setting expectations on mocks. Note: this trait also provides the lastCall method, which just calls expectLastCall. This allows you to avoid writing "expect" twice. Also, the reason expecting doesn't take a by-name parameter, execute that, then call replay is because you would then need to pass your mock object or objects into expecting. Since you already need to pass the mocks into whenExecuting so that verify can be invoked on them, it yields more concise client code to have whenExecuting invoke replay on the mocks first rather than having expecting invoke replay last.

Once you've set expectations on some mock objects, you must invoke replay on the mocks to indicate you are done setting expectations, and will start using the mocks. After using the mocks, you must invoke verify to check to make sure the mocks were used in accordance with the expectations you set on it. Here's how that looks when you use the EasyMock API directly:

   replay(mock)
   classUnderTest.addDocument("Document", new Array[Byte](0))
   classUnderTest.addDocument("Document", new Array[Byte](0))
   classUnderTest.addDocument("Document", new Array[Byte](0))
   classUnderTest.addDocument("Document", new Array[Byte](0))
   verify(mock)
   

This trait enables you to use the following, more declarative syntax instead:

   whenExecuting(mockCollaborator) {
     classUnderTest.addDocument("Document", new Array[Byte](0))
     classUnderTest.addDocument("Document", new Array[Byte](0))
     classUnderTest.addDocument("Document", new Array[Byte](0))
     classUnderTest.addDocument("Document", new Array[Byte](0))
   }
   

If you are working with multiple mock objects at once, you simply pass them all to whenExecuting, like this:

   whenExecuting(mock1, mock2, mock3) {
     // ...
   }
   

The whenExecuting method will first invoke EasyMock.reply once for each mock you supplied, execute the passed function, then invoke EasyMock.verify once for each mock you supplied.