You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I know, I know, we try really hard to push the whole "static functions are bad, mmmkay" message. Bear with me though, because either there's some work to do or I need some help coming back to sanity.
So lately I've been trying to decide what this extension is for exactly. When I started using it, it was an opinionated tool that was moving towards the idea of Magento modules been decoupled from the framework. If a module was decoupled and supported some bastardised form of DI then we could test code in isolation, and that sounded great. Sure, there were still some bumps in the road that lead to some very curious behaviour when Varien's magic conflicted with phpspec's magic, but generally we could drive our module writing with specs and all was well.
More recently though I've been getting on board with the idea that it's business logic that should not be framework specific. Objects that represent the domain of the business, and therefore the core value of a project, should be libraries of pure language, with interfaces provided wherever an edge exists. This allows for an ease of transition between entire frameworks, but leaves Magento modules as rather thin wrappers between the framework and generic library code. Generally there is no need for a tool to drive the design of thin framework wrappers, that can be safely covered by integration tests. So what is MageSpec for?
Pragmatism
Sometimes, for whatever reason, separating code out into an external library just isn't worth the effort. Maybe there is very little chance the code will be reused. Maybe there needs to be some framework specific logic that would be just too absurd to decouple.
Utility
Generating XML is the example that comes foremost in my mind. Nasty repetitive tasks that can be easily automated.
Gateway drug
A lot of developers who have learned their craft with Magento are not familiar with TDD or SpecBDD or whatever we're calling it these days. They often see MageSpec as a drop in replacement for PHPUnt, and become confused when their tests blow up because of framework coupling.
Add support for static functions
I'm hoping that this overly long issue will generate some feedback on the idea that I'm toying with, namely that MageSpec could support Magento's static functionality in some way. I'm not really thinking of implementation details yet, but I'm thinking about stuff like:
Magento class loading methods return doubles
Custom matchers for other static interactions like loading config or logging
Doubles of Magento objects support all the magical behaviour of Varien objects without the framework bootstrapping
All of the above enabled/disabled by a 'strict mode' config option
What do you all think?
The text was updated successfully, but these errors were encountered:
Trying to extend/rewrite a core controller and using: require_once Mage::getModuleDir('controllers', 'Mage_Customer') . DS. 'AccountController.php'; will fail without access to Mage.
I know, I know, we try really hard to push the whole "static functions are bad, mmmkay" message. Bear with me though, because either there's some work to do or I need some help coming back to sanity.
So lately I've been trying to decide what this extension is for exactly. When I started using it, it was an opinionated tool that was moving towards the idea of Magento modules been decoupled from the framework. If a module was decoupled and supported some bastardised form of DI then we could test code in isolation, and that sounded great. Sure, there were still some bumps in the road that lead to some very curious behaviour when Varien's magic conflicted with phpspec's magic, but generally we could drive our module writing with specs and all was well.
More recently though I've been getting on board with the idea that it's business logic that should not be framework specific. Objects that represent the domain of the business, and therefore the core value of a project, should be libraries of pure language, with interfaces provided wherever an edge exists. This allows for an ease of transition between entire frameworks, but leaves Magento modules as rather thin wrappers between the framework and generic library code. Generally there is no need for a tool to drive the design of thin framework wrappers, that can be safely covered by integration tests. So what is MageSpec for?
Pragmatism
Sometimes, for whatever reason, separating code out into an external library just isn't worth the effort. Maybe there is very little chance the code will be reused. Maybe there needs to be some framework specific logic that would be just too absurd to decouple.
Utility
Generating XML is the example that comes foremost in my mind. Nasty repetitive tasks that can be easily automated.
Gateway drug
A lot of developers who have learned their craft with Magento are not familiar with TDD or SpecBDD or whatever we're calling it these days. They often see MageSpec as a drop in replacement for PHPUnt, and become confused when their tests blow up because of framework coupling.
Add support for static functions
I'm hoping that this overly long issue will generate some feedback on the idea that I'm toying with, namely that MageSpec could support Magento's static functionality in some way. I'm not really thinking of implementation details yet, but I'm thinking about stuff like:
What do you all think?
The text was updated successfully, but these errors were encountered: