Add a lithium mocking class with an autoloader. #755

Merged
merged 1 commit into from Dec 19, 2012

Projects

None yet

2 participants

@blainesch
Member

I do not like how the code is currently being stored in a variable
on the class.

I do not like how I am using eval to get this job done.

Code Complexity: 1.75
Code Coverage: 100%

Blaine Schmeisser Add a lithium mocking class with an autoloader.
I do not like how the code is currently being stored in a variable
on the class.

I do not like how I am using eval to get this job done.

Code Complexity: 1.75
Code Coverage: 100%
195c6b8
@blainesch
Member

Fix for #750

@nateabele
Member

You didn't say "I do not like them, Sam I am", but okay.

@nateabele nateabele merged commit 5975540 into UnionOfRAD:dev Dec 19, 2012

1 check passed

Details default The Travis build passed
@blainesch
Member

I was hoping there would be a little more discussion about this. I'll try and write up a better class doc tonight or tomorrow with a few examples.

I thought of an issue with this and I can think of two possible solutions. The issue is that because $results is generated -before- the filter it's possible the results could manipulate the class. At which point your filter and the original method are both ran and we edit the same thing twice. Your filter may simply overwrite what the default method does, or both may add to an array.

We -could- attempt to open the file up, copy/paste in some lines from the method, making sure the method has a $that reference and doing a string replace. This seems kinda messy and we still run into an issue with trying to access protected/private methods.

Another idea, is to just overwrite the default visibility of methods, since in PHP you can always make a method more visible, we could just force all methods to be public in the mock and move the call from out of the filter to inside of the filter.

Thoughts?

@blainesch
Member

I created a unique 2 parent system.

First extend the class and make all method public and add some logic to the methods.

Second we extend that and overwrite the constructor, and create an instance of the object first step class, we recreate all methods and make them filterable and call the stored mock.

Back on the first class we check to see who's calling who. If the second step mock is calling it we pass it along, if not we send it through the second step mock.

The only downside I see to doing it this way would be that the base class that we mock needs to call "static" instead of "self" which should be happening anyways if you ever plan on extending it.

If I don't make sense I made an example gist here. I'm not sure why the formatting is messed up but it's fine if you view raw.

@nateabele
Member

I was hoping there would be a little more discussion about this [...] I thought of an issue with this and I can think of two possible solutions.

We're in between releases, and you implemented something decent where we currently have nothing. It's okay to start somewhere and improve incrementally, so long as it's clean by the time we release.

The only downside I see to doing it this way would be that the base class that we mock needs to call "static" instead of "self" which should be happening anyways if you ever plan on extending it.

We only have a couple of calls to self in the framework, and always advocate static over it. I don't see why this should be a problem.

@blainesch
Member

I almost have something to commit on top of this with some docs on how to use it and a few more unit tests to cover the patch.

When is the 0.12 release scheduled? This patch should be submitted within an hour or so unless something goes horribly wrong (like the end of the world).

@nateabele
Member

Assuming no end-of-the-world scenarios, the next release is planned for a few weeks from now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment