Project Roadmap

[alganet]

We were thinking of a global, temporary project map (to be updated) with our priorities for the projects we handle.

Of the items we discussed, I remember:

• A 2-week bug hunt to stabilize each component then release 1.0 for Rest, Relational and Template
• A better website and end-user in prose documentation
• Improved support channels through IRC and GitHub, proper flags and milestones
• Fully switching to PSR-1 and PSR-2
• Normalizing project structure (folders, config files, test approach)
• Creating better unit tests (similar to Validation)

Items not in specific order. Anything to discuss?

[nickl-]

• A 2-week bug hunt to stabilize each component then release 1.0 for Rest, Relational and Template

I agree these are core for end users but I would like to see on the list, maybe not production ready but actively in use internally never the less.

• Foundation - it is the only way we should attempt to normalize because then it doesn't matter if the panda's are not 100% happy with our new "normal", subsequent change will be manageable.
• Doc - needs work what I see there is hardly more than a proof of concept and it doesn't make sense to do a project normalization walk without the means to document simultaneously. Your thoughts?

• A better website and end-user in prose documentation

I think our presence on each repository/sub project should be consistent this definitely needs to be addressed. IMO we have a website it's better than none, we even have a PEAR channel on there bonus. We have the Rest documentation up on xxxxxxxx (that place) another plus. We can live with those for now, unless I am not fully grasping what you have in mind.
What we might want to do is see about the PEAR2 channel?

• Improved support channels through IRC and GitHub, proper flags and milestones

As per the previous we want consistency and you should be able to recognize you are on our turf somehow, that would be the ultimate. Either way consistency, markdown, naming conventions, directory structure and the presence of files, if we are employing travis then travis on every project. They must all look and be wrapped with the same Respect awesome!

• Fully switching to PSR-1 and PSR-2

I'm glad there is no question about this and we are all on the same page. Foundation will be able to aid in this regard already.
Along with the style fixing should be code comments and mild refactoring. At least flag areas that should raise concerns. I think PhpDocumentor2 can generate reports pointing out grey zones with no or little code comments. am not necessarily pushing for any specific tool just looking at what seems useful to make this task manageable.

• Normalizing project structure (folders, config files, test approach)

Ditto

• Creating better unit tests (similar to Validation)

I think this sums it up, lets not wait for PSR-8 to tell us to add annotations and separate data from logic in unit tests. We have made a commitment to 100% coverage lets do that, lets have the tools available to easily view the coverage and this should be a higher priority than even tests failing iow if the coverage is 100% we can fix the tests that fail after that, but any 60/70 % code blocks should get pandas in high alert. Another thing that makes us different and standing out above the rest then.

---

Sebastian Bergmann - PHPUnit best practices

It's getting a bit dated now I know but what I want to point out specifically are the points with regards to

Best Practices for Code Coverage

• Use Code Coverage Whitelisting

<?xml version="1.0" encoding="UTF-8"?>
<phpunit backupGlobals="false"
         backupStaticAttributes="false"
syntaxCheck="false">
  <filter>
    <whitelist addUncoveredFilesFromWhitelist="true">
      <directory suffix=".php">path/to/dir</directory>
    </whitelist>
  </filter>
</phpunit>

• Make the Code Coverage information more meaningful

<?php
class FooTest extends PHPUnit_Framework_TestCase
{
    /**
     * @covers Foo::doSomething
*/
    public function testSomething()
{

<?php
/**
* @covers Foo
*/
class FooTest extends PHPUnit_Framework_TestCase

<?xml version="1.0" encoding="UTF-8"?>
<phpunit mapTestClassNameToCoveredClassName="true"
              forceCoversAnnotation="true">
</phpunit>

• Testing What Should Not Be Tested
  • A class with private attributes and methods
  • Assertions on non-public attributes

---

The last points about testing stuff that should not need testing, besides the extra difficulty of penetrating the privacy scope to test functionality that is not exposed in any case, in combination with mapTestClassNameToCoveredClassName which is probably already being written to PSR-8. The point is it doesn't have to be difficult or even a lot of work just map the classes 1class to 1Test, cover all the exposed functionality (public methods and properties, hide the rest) describe the tests properly with @covers annotations and the majority of the work will be done already.

I have already worked those settings into the default phpunit.xml which Foundation will provide along with several after tools that will assist us , expect me to wrap it up soon.

[alganet]

Since everyone agrees, we should start with the bug hunt then!

The purpose of Respect\Doc is to avoid DocComments and Annotations as much as possible. Use them only when necessary. On the Respect\Doc-world all documentation should come from well-written tests (unit, behavior or any other).

I do agree about consistency. We do decoupled components, but the development process is the same and should produce similar software. Perhaps the projects hibernating (like Doc, Http, Structural) could be marked as such and put aside, but I believe if we fix Foundation properly migrating them to a normalized structure wouldn't be so hard.

Our tests currently aren't unit tests. Perhaps only Validation have proper unit tests (because it's easy do to there). Our tests are more BDD-ish, and we should move that to a proper BDD suite (like Behat).

The fix for the things that shouldn't be tested are mocks, but they're expensive and I was lazy when writing them. Only now I deeply regret my lazyness, we should use them more often.