Closed mepox closed 1 year ago
Hi @bglamadrid ! I would like to do this one too.
@mepox here you will need to pull and merge main
into your local branch too, due to #157.
@mepox here you will need to pull and merge
main
into your local branch too, due to #157.
Regarding on this I think its a good practice to update fork repos everytime if there is an update and then merge locally if PR is raised 😁
Regarding on this I think its a good practice to update fork repos everytime if there is an update and then merge locally if PR is raised 😁
And if any of you find yourselves in trouble while resolving conflicts, you can -and totally should- ask for help. Now you can open a new thread in Discussions for this 👌
@bglamadrid So I guess, now I can use and add @Builder annotation to Pojos that I need for my tests, right?
Edit: And fix classes where the annotation cause problems, for example in some converters which right now uses the Pojos default constructor..
Edit2: Or add those converter changes to a separate PR?
@mepox You can use Pojos annotated with builders, but you should refrain of annotating pojos yourself unless you're including them as part of new functionality. This issue is not fit for that.
If you have a problem with building or testing the code before you even begin, you probably are missing the latest changes from main
.
Make sure to fetch & pull often, and always do both before creating new branches.
From #88
ReceiptServiceImpl
should have unit tests that ensure it complies with the interface and methods it implements,IReceiptService
.No need to provide coverage for
private
methods, only the@Override public
ones from the aforementioned interface.This interface provides a single method that must fetch receipt information for a given order, given its transaction token (which is created at the beginning of the checkout process).