New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[5.5] add assertDispatchedTimes for event fakes #22528

Merged
merged 1 commit into from Dec 24, 2017

Conversation

Projects
None yet
5 participants
@ekateiva
Contributor

ekateiva commented Dec 24, 2017

Hey,

I find it useful to test how many times the event was dispatched. I exposed the method assertDispatchedTimes(), however you can pass ant int to assertDispatched() instead of a callback, so you can use Event::assertDispatched(SomeEvent::class, 3).

@taylorotwell taylorotwell merged commit a55c4bf into laravel:5.5 Dec 24, 2017

2 checks passed

continuous-integration/styleci/pr The StyleCI analysis has passed
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@sisve

This comment has been minimized.

Show comment
Hide comment
@sisve

sisve Dec 25, 2017

Contributor

This is a change in a method signature and a breaking change.

Contributor

sisve commented Dec 25, 2017

This is a change in a method signature and a breaking change.

@vlakoff

This comment has been minimized.

Show comment
Hide comment
@vlakoff

vlakoff Dec 27, 2017

Contributor

Actually, there are no signature changes ;)

Contributor

vlakoff commented Dec 27, 2017

Actually, there are no signature changes ;)

@GrahamCampbell

This comment has been minimized.

Show comment
Hide comment
@GrahamCampbell

GrahamCampbell Dec 27, 2017

Member

Actually, there are no signature changes ;)

There is, because the 2nd param's type signature has changed. There are just no static signature changes.

Member

GrahamCampbell commented Dec 27, 2017

Actually, there are no signature changes ;)

There is, because the 2nd param's type signature has changed. There are just no static signature changes.

@ekateiva

This comment has been minimized.

Show comment
Hide comment
@ekateiva

ekateiva Dec 27, 2017

Contributor

I am not sure why you count it as a breaking change. Actually, the param has not changed, just the new type of it was introduced. However, the functionality is 100% backwards compatible.

Contributor

ekateiva commented Dec 27, 2017

I am not sure why you count it as a breaking change. Actually, the param has not changed, just the new type of it was introduced. However, the functionality is 100% backwards compatible.

@GrahamCampbell

This comment has been minimized.

Show comment
Hide comment
@GrahamCampbell

GrahamCampbell Dec 27, 2017

Member

The problem is that someone extending the class, overriding the method, now suddenly has to support more types for that parameter, and that is what's technically breaking here.

Member

GrahamCampbell commented Dec 27, 2017

The problem is that someone extending the class, overriding the method, now suddenly has to support more types for that parameter, and that is what's technically breaking here.

@GrahamCampbell

This comment has been minimized.

Show comment
Hide comment
@GrahamCampbell

GrahamCampbell Dec 27, 2017

Member

Those sort of breaking changes are common place in laravel's patch releases though, so I wouldn't bother with reverting or retargetting 5.6, unless someone is actually burnt bad by this.

Member

GrahamCampbell commented Dec 27, 2017

Those sort of breaking changes are common place in laravel's patch releases though, so I wouldn't bother with reverting or retargetting 5.6, unless someone is actually burnt bad by this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment