Replies: 3 comments 1 reply
-
Agree on this. I don't know if this is currently possible due to proxied chained calls, but this a simple example to understand why it would be useful: test('::getNickname() will return the user nickname')
->tap(fn () => User::factory()->create([
'nickname' => 'foo',
]))
->expect(fn (User $user) => UserService::getNickname($user->id))
->toBe('foo'); I know this could be translated to We can of course move everything inside "expect", but we would lose the elegance and simplicity of a one-line-arrow-function: test('::getNickname() will return the user nickname')
->tap(fn () => User::factory()->create([
'nickname' => 'foo',
]))
->expect(function () {
$user = User::factory()->create([
'nickname' => 'foo',
]);
// Maybe do something else here
return UserService::getNickname($user->id);
})
->toBe('foo'); |
Beta Was this translation helpful? Give feedback.
-
Indeed, although I was more thinking along the lines of. test('example test', function() {
expect(User::factory()->create())
->name->toBe('Jane Doe')
->tap(function (User $user) {
expect($user)->toBe($user->fresh())
});
}); Where here I have an existing expectation and tapping into it gives me its value. |
Beta Was this translation helpful? Give feedback.
-
When tapping into an expectation I think it would be great if the value of the expectation would be passed as the first argument, or maybe last to maintain backwards compatibility, of the closure provided. This would allow users to more easily perform actions on the value of the expectation itself while still using higher order expectations and tests.
Beta Was this translation helpful? Give feedback.
All reactions