Closed design365joe closed 7 years ago
Hey @design365joe! The reason I did it that way is because we didn't need all of the extra meta data for any reason yet, so rather than do a ton of work to make the FakePaymentGateway simulate features we weren't actually using, we kept it simple and just dealt with the amount.
You'll see once you get to this module that we introduce "charges" as a proper domain concept, and add more functionality to our fake:
https://course.testdrivenlaravel.com/lessons/module-14/promoting-charges-to-objects#83
Fair enough - I guess the most important part of my original post (that I didn't realise) was "[data] that we may potentially need later on". Cheers for the speedy reply, and the excellent series so far!
Between lesson 62 and 63, we write a small bit of code for testing the
newChargesDuring
method. Here's what I expected that we'd end up with:In actual fact, on the
return
line you recommend adding in->pluck( 'amount' )
to make the FakePaymentGateway slightly less noisy. The idea being that since we want to be able to test both in the same way, there's no reason to tie that into having to return anamount
key.By doing this though, aren't we gimping the StripePaymentGateway? We're discarding a huge amount of data about each real payment (that we may potentially need later on) for the sole purpose of making the FakePaymentGateway marginally cleaner.
I'm sure there's a good reason that this is really a better solution, but right now I don't understand what that reason is.