The verify actually fails because the in-memory version of the Account a used in the uow.registerNewhas changed after the registerNew was performed. When the mocks.verify executes, a.Name = 'Bar' !
This was a bit counterintuitive to me as I was expecting the mocking system to capture the arguments at the time of the uow.registerNew(a) and thus be verifiable later.
Now, why did this issue come up? I had a bulk processor that was accepting events from a 3rd party system. Within the transaction, new Accounts would be created (uow.registerNew) but if the same account was found later in the batch, a uow.registerDirty would be done on the Sobject held in memory from the insert. I relied on the fact that fflib_SObjectUnitOfWork does inserts first, then updates, so the coding pattern worked well.
Obviously, I can rework the verify statement but if there's a technical solution to this, that would be great.
I'm not sure there is an answer to this but consider the following (assumes fflib Unit Of Work pattern)
and this verify ...
The verify actually fails because the in-memory version of the Account
a
used in theuow.registerNew
has changed after theregisterNew
was performed. When the mocks.verify executes,a.Name = 'Bar'
!This was a bit counterintuitive to me as I was expecting the mocking system to capture the arguments at the time of the
uow.registerNew(a)
and thus be verifiable later.Now, why did this issue come up? I had a bulk processor that was accepting events from a 3rd party system. Within the transaction, new Accounts would be created (
uow.registerNew
) but if the same account was found later in the batch, auow.registerDirty
would be done on the Sobject held in memory from the insert. I relied on the fact thatfflib_SObjectUnitOfWork
does inserts first, then updates, so the coding pattern worked well.Obviously, I can rework the verify statement but if there's a technical solution to this, that would be great.