Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
How to organise the Driver interface? #21
As noted via e-mail, the Driver acts as an interface for communication between Behat and WordPress (creating, deleting, asserting properties of) content/users/options/terms etc.
The Driver, therefore, could grow quite large. One suggestion is to compartmentalize each WordPress 'entity' (content, users, etc) So rather than:
it would be
I don't foresee any reason to be able to swap out, say, the
Broadly, yes. Not sure of the implementation. Thinking out loud, DriverInterface would have to be split up into (terrible name but) DriverInterfacePart. Each Part would have stubbed methods for CRUD-actions.
DriverInterface would remain with bootstrap methods/constructor. It'd need an array or something to store the DriverInterfaceParts (class properties would probably be OK, like you've implied, would end up with lots, though!). We can use dependency injection to have Symfony create these and pass to constructor (I don't know how to do that 100%, still learning about Symphony and DI, but i've done it before elsewhere in this project)
I think it's time to sort this out. I still agree with your suggestions. My thoughts:
That keeps the main Driver class very light as we would use an array to store all Collections.