Open ctasca opened 10 years ago
Ideally people would not use MinkContext. This context provides too low level language. The Magento context should include elements of MinkContext as relevant and also domain specific steps.
Using MinkContext encourages feature definitions and steps that focus on implementation such as clicking links.... filling in forms one field at a time. This is great to get started but can become problematic as implementations change.
We constantly debate weather we should make it compatible with MinkContext or duplicate the step definitions.
The symfony2 context is a good example.
I have been using MinkContext mainly because I am using Mink with Sahi Driver, and works better when inheriting methods from MinkContext rather than RawMinkContext. There is so much JS on admin side of Magento I thought Sahi would be better.
I was just wondering if renaming it would help who has this type of setup and prefer using MinkContext, but will have a look at symfony2 one as you suggested.
Thanks
As a temporary workaround its possible in php5.4 to use MinkDictionary as a trait.
class MyMagentoContext extends MagentoContext
{
use MinkDictionary { visit as private; }
private $output;
public function __construct(array $parameters)
{
//$this->useContext('mink', new MinkContext);
}
I'll also have a look at the symfony2 context.
I have implemented the workaround as described by Rud5G. I really did not feel like rewriting everything from MinkContext as it really has some very useful default functions.
This exception is thrown when trying to use MinkContext in a subclass of MagentoContext.
In this scenario:
behat.yml
WHERE MyMagentoContext is in composer autoload and have following constructor:
and AdminUserContext is defined as follow
WHEN I run command
I get
To make it all working I need to remove iAmOn from MagentoContext class. Maybe it should be renamed?
Thanks