eko/certificationy — pull request #40 by cleentfaar (2014-06-29 23:29:05+00:00)
Title: Massive refactoring to promote separation of concerns

Hey again @eko / contributors!

I found some more time to get a big refactoring going of the Certificationy codebase, I hope you guys get some time to check it out and hopefully approve it for merging. I've listed all of the changes below:

- Refactored ``Loader``:
- Split ``Loader`` class up into two separate classes, namely ``SetFactory`` and ``QuestionLoader``, further promoting separation of concerns.
- Made the ``QuestionLoader`` to be specific for loading questions from files, an optional path to files and can be given, and methods were split up further.
- No static classes or methods needed anymore (if it's not necessary don't do it, is my opinion).
- ``QuestionLoader`` only loads files once (during construction), and can access any category from there on.
- All content that is loaded from files is checked against pre-configured ``OptionsResolver`` instances so that access to a question's options is assured after construction.
- Made the randomizing of questions optional in the ``create`` method, allowing for the ``--randomized`` option in the command.
- Applied more phpdocs where needed.
- Refactored ``Set``:
- Added ``getScore`` method that will return the total score achieved after adding the answers. The score is determined by counting all correctly answered questions and multiplying them by the ``weight`` for each question (see the explanation about ``Question`` below).
- Made number of questions accesible through a new ``count()``-method.
- Refactored ``Question``:
- 4th argument added to constructor: ``$weight``, allowing the weight of a question to be configured. It determines how important it is during a test to answer this question correctly (value between 0 and 1, see explanation in ``Set`` above).
- Changed ``getAnswerLabels()``-method to return the labels starting from index ``1`` instead of ``0``; this has a much nicer presenation during a test (the ``TestCommand`` has been refactored for this appropriately, see below).
- Refactored ``StartCommand``:
- Renamed to ``TestCommand`` to be more applicable to it's function within the application (**starting** a test is not the goal, it's to **do** a test).
- Refactored to be compatible with the changes to the classes above.
- Changed the ``categories`` **argument** to be an **option**; it's not required to do a test.
- Added ``--randomize`` option that defaults to true for flexibility: if users want to repeat a specific order of tests later they can use ``--randomize=0``.
- Added score result to the final output including a humanized response to hopefully cheer users on to improve their score (uses ``getScore()`` from the ``Set``-changes mentioned above)
- Added ``--env`` option to differentiate configuration used within the command. Currently used to determine the path to the ``.yaml`` files. E.g. for ``env=test`` it's a special testing directory so that the ``TestCommandTest`` can pass independently from what files users add to the normal ``data`` directory, which should not affect the core's tests (see test-refactoring below).
- Refactored tests:
- Fixes to make existing tests work with these changes.
- Added new tests for the new ``QuestionLoader`` and ``SetFactory`` classes.
- Added ``--env=test`` option to the command-test so specific (suited for tests) configuration can be used by the command (see ``TestCommand`` refactorings above).

Lastly, I went as far as adding my author entry to the ``composer.json`` file and some of the classes on which I feel I've made a big contribution with this PR and the ones before. Let me know if you feel they are off-limit.

Thanks for checking!