[Proposal] abstract the core of the application

[RageZBla]

During the few hours, I have worked on this project I have encountered few issues that has been bothering me. BTW your software is awesome 👍 and I hope it continue to grow and evolves so please don't take this proposal the wrong way. 🙇

At the moment the actual server management tasks (such as adding users, adding groups to users, listing users etc) are not abstracted at all. Most of the code directly lives in the controllers.

This create several issues:

• it reduces the code re-use possibilities
• it makes testing difficult and force to test at integration/end to end level
• related to previous point but having tests using mock/fake implementation would allow to use docker instead of vagrant (not 100% related)

In my opinion, it would wise to create some interfaces and encapsulate the actual server management tasks into specific objects/classes. In that scenario the tests could use some fake implementation and it would allow to write unit tests.

Something like the hexagonal architecture could be beneficial to the project.

I would volunteer to do the refactoring, I just want to coordinate and verify that my proposal make senses before starting anything.

[RageZBla]

@dshoreman can I have your opinion about this?

[dshoreman]

@RageZBla Thanks for the feedback! This all sounds great, in fact refactoring has been on the todo list for some time but I never added it as an issue specifically.

The System User/Group management code all needs abstracting away from the controllers (issue #141) so they can be auto-created for certain projects later.

Currently file management piggy-backs on the Symfony components, but that will also need a refactor so we can more easily fix #103 and #119. Especially the latter which will require that we re-implement file handling ourselves to avoid opening "personal" things (eg SSH config) as www-data and getting permission denied.

---

The difficulty in using Docker comes not from testing, but the fact that Servidor (currently) relies on everything being installed on a single server in order to read/write configs, display system stats etc. That said, having tests use mocks/fakes instead of hitting the physical underlying system could also help resolve issue #139 where dir listing tests cause warnings in the Travis output.

[dshoreman]

Following up on this issue, it seems there are a few requirements before it can be closed:

• Refactor FileManager (related: Can't view folders/files unless www-data has permission #119)
• Refactor System\UsersController
• Refactor System\GroupsController
• Add extra tests where required
• Use mocks/fakes instead of real exec() calls

The users refactor is done and will be merged soon.