What are Mockolate changes in 0.12.x?

[John]

Poking around the mockolate.org and Github pages has beeb unfruitful. Could you help me identify the changes sinice 0.11?

[Drew Bourne]

0.12.0

- introduced `expect()` and `allow()` for defining non-stringy refactoring-friendly expectations, use instead of `mock()` and `stub()`

- cache already prepared proxy classes

- fixed mocking of classes in the default (empty) package

- added support for [Mock] to allow defining constructor arguments to pass to the instance using a public field or method of the test class.

- added support for [Mock] to allow defining namespaces to proxy using a public field or method of the test class.

- improved support for proxying namespaced methods and properties

0.12.1

- fixes for features introduced in 0.12.0

0.12.2

- add support for constraining an Expectation using States / StateMachine

- deprecate `record()` and `replay()`, replacing implementation with no-op as unneeded.

0.12.3 (didn't push to GitHub)

- update metadata.xml with missing options

0.12.4

- fixes for weak event listener causing occasional test runs to stop indefinitely

0.13 (master, not yet released)

- add new Spy API as non-stringy refactoring friendly alternative to `assertThat(target, received().method("call").once())`

- improve all error messages to be very descriptive about which target, expectations, invocations 

- fix nice mocks to valid invoked counts, eg: `.once()` will no longer pass if invoked twice. 

- deprecate the chaining after `verify()`, eg: `verify(target).method("call").once()` will be removed in 0.14. (not yet done)

- add this list of changes to a CHANGELOG file. 

I'm working actively on updating the docs and the site for 0.13 for all the new features and recommended practices. 

HTH,

Drew

[Roland Zwaga]

I don't think it can be said enough: Drew, you're doing an amazing
job! Keep at it!

Drew Bourne <dr...@firstbourne.com> schreef:

[John]

Very helpful, indeed! I'd like to use expect, so I'll see if I can figure it out.

One thing that I'm uncertain of is whether multiple events can delivered as a result of method(a).dispatches(y).dispatches(z). Would this cause the listener for y to fire followed by the listener for z?

Based on what I see below, it seems the preferred style would be expect() with no calls to record()/replay().

Thanks very much!
John

[Drew Bourne]

Calling `.dispatches(y).dispatches(z)` will dispatch those events in the given order. You can also specify a delay if you would like to trigger the events async: `.dispatches(y, 10).dispatches(z, 200);`

Calls to `record()` and `replay()` are redundant now and can be removed. 

One case to note: if you are using strict mocks you need to wrap calls to `expect()` in `expecting()` which defines a safe context within which invocations can be made against strict mocks. eg: 

    var thingy:Thingy = strict(Thingy);

    expecting(function():void {

        expect(thingy.gimme()).returns({ other: "thing" });

    });

cheers, 

Drew