I think it would be a good rule for PHP code that there’s one and only one method which access private fields directly. Even if rules of OOP allows you to access private field – it’s most definitely bad idea to do so. If you need no public getter – make private one.

This is only one case. To have it fully covered I should create method for state 1. And the add requirements that the other method is not called at all. Lot’s of work, and more coming if more cases appear (remember – this is payment method, and those are never enough for your client).

This is road to nowhere. If such simplified example seems not to be problematic – try for yourself add 5 cases. Then manage in some reasonable way list of methods which should and should not be called. How do you refactor? Extract $methodsWhichShouldNotBeCalled, use dataProviders? But there’s an easier way.

Enter polymorphism. It’s not just something you had to learn on your OOP course and what sophisticated programmers talk about. It’s also making programming simpler. And since writing test is also programming – it will make your tests simpler.

First I defined interface, and simple workers which represent different methods which has to be performed for different payment methods:

No branching. Of course – first line also needs some attention (it’s a implicit dependency of your class, so you would rather pass methodFinder as a param or use some kind of service locator to make it mockable and be able to test that “doJourJob” is called on whatever it returns. But that’s a detail and it depends on your architecture and other constraints.

As a closure I’ll tell you a secret: it’s a design pattern. I honestly don’t remember how it was exactly called. Some mixture of strategy and factory… I guess. To find out read about patterns and try to find the one that fits ;) This is your homework – leave a comment when you find out.

The search uses prefix matching so the entire branch name does not have to be typed into the search field. The search for `is:open head:feature` will also match a branch named “feature-api-enhancement”.

We hope you enjoy this new feature. As always, please send us an email if you have any questions.

TwP

I wonder what kind of system they use – my support request/ticket must have been linked with feature/user story.