What's next with FriendlyContexts?

[pimolo]

Roadmap 🗒

Refactor the documentation

At the moment, the documentation is suffering from lack of details, consistency and formatting.
That’s going to be fixed for the next release.
It will be kept on Github, which is readable enough with a proper usage of markdown.

Remove Smart Steps

Smart steps are quite useful when you have many tests with a common part (most of the time it’s for authentication).
But, first it makes your tests not isolated, because they are dependent of other tests (which are one of the main principles of testing), see #232.
Then, when you define smart steps, you may not need to execute them entirely when reused.
The feature itself is pretty heavy and slows the whole tests suite, even if you don’t use smart steps! (#225)
So we decided to remove this feature. It’s a huge BC Break but we are convinced that it’s for the best.

Enable feature toggling

We are also considering the ability to activate or disable every userland feature of the lib.
Actually it’s mainly for performance : if you don’t use a feature, you don’t need it to be used in your test suite. It can be useful since impact performance a lot.

About internal tests

This lib needs also a few more tests. It already has some tests that we could compare to unit tests but we also need some functional tests.
So for the next major release there will be tests with Behat + Mink.
We probably will use PhantomJS but we want to give Chrome headless a try though.
Anyway the test suite is still to be defined.

MOAR contexts

Sometimes it’s quite useful to have some Context classes for third-party services that are used in some features, in order to give more consistency to the tests.
For example, we often see Context classes for mailers, message brokers, commands.
So don’t hesitate your share your contexts!

Httplug integration

Maybe one of the most expected demand in this repo. And for good reason : in composer.json the required client is Guzzle 3! So we need to use an abstraction so FriendlyContexts can be used with any PSR-7 compliant HTTP client, without bringing a mess in your project.

About versionning

Let’s be clear : we are working on some refactoring that could end up with some BC breaks. This refactoring is necessary in order to introduce some next changes.
Don’t worry, we won’t touch the master branch until the next big release (we know that many users required the lib with dev-master since it’s recommended in the documentation).
So from now, bugfixes and new features should point on the 1.x branch.

All these topics already have some issues or PRs!
We need some help to move forward on these topics, so don't hesitate to take a look at them and ping @Nek- and I.
We are also open to questions/feedback, and we can't wait to see them!