Closed andreiashu closed 10 years ago
Hello @andreiashu,
Sorry for my late reply.
I really don't have time to follow this repository right now and wanted to ask if you would agree to become a collaborator for this repository to take care of it?
Cheers, Dan / sixty-nine
Hi, will take a look at it over the day. See if I understand what you did ;) Thx for contributing!
Hey Bastian, Dan, Thanks for your reviews guys. Bastian: I'll update the pull req, indeed I haven't had time to do proper documentation for it. Re understanding what it does: before committing this code I'll need to push a unit test for this class. That could act as documentation as well.
Dan: thanks that would be great. We are using this repo in our project and I should have time to help with its maintenance
Thanks
Andreas, UTs are very much appreciated and do indeed satisfy me as documentation.
So I will wait until the PR updates.
@andreiashu you are now collaborator of this repo. the recommendations of Bastian are still valid for this PR. thank you for your collaboration
Hi guys, it took me a while to get back to this pull request but I finally pushed the unit tests and better documentation. I also fixed all the notes regarding docblocks. Let me know what you think
Adds a new cache class DrupalInMemoryCache so that during unit testing the DB/Memcache cache layer is not being polluted. This gives us the ability to have a clean () cache at the beginning of each test. () The cache that has been constructed during bootstrap is being restored at the end of each test.
There is a line in the phpunit.xml file which makes this system optional, but enabled by default (because test isolation is crucial).
Caveat: if the subclass extends either setUp or tearDown methods but doesn't call the parent method this implementation breaks. This caveat is valid for the changes in the pull request no #4. One possible solution for this is to use subclass of PHPUnit_Framework_TestSuite to run the tests in which we move the clearing of the caching outside of the setUp/tearDown method.
Performance implications: I haven't profiled the serialize/unserialize steps at all. Compared to a full drupal bootstrap (especially in a large installation) that performance hit should be negligible. Also as mentioned before, test isolation is critical.