I don't even want to go through the list of all the stuff I did today, trying to get my TYPO3 PHPUnit tests to run successfully from within Eclipse. I spent the last 2 hours of yesterday evening trying things out, and today it went on as I tried some new ideas I'd gotten while washing dishes this morning, and then going back to basic concepts by reading everything I could find on PHPUnit and Eclipse.
Unfortunately the majority of articles online about this topic are from 2011 or 2012.
I wrote a phpunit.xml and a bootstrap.php file for the project and, along the way, learned some interesting things about Eclipse that helped me to understand it better, like how I can set up a view for PHPUnit output in its own window and set up a button in the toolbar for running the unit tests with a click of a button instead of right-click - select - select, open console because it won't stay pinned and disappears as soon as I right-click on a file in the project-tree... (I found out that you can fix that by selecting "Restore" within the console window).
My final strategy was that on which I stumbled yesterday evening: google the error-message. "Fatal error: Call to undefined method PHP_CodeCoverage_Filter::getInstance()". What I found is that there are two possible PERL libraries for PHPUnit to use in Eclipse, thus there are two possible "Filter" classes for PHP Code Coverage. The one being used no longer has the method being called - it has no constructor and looks like an older model.
I guess that when the code for PHPUnit in Eclipse was updated, IT WAS NOT TESTED WITH PHPUNIT. OH THE IRONY.
What I did was make a copy of each Filter class and include both of them in each library. Then in the file where the error is raised, I changed the require_once directive to require the file with the needed code.
The reason I did this is because though I entered both PERL paths as the PHPUnit libraray in Eclipse, whichever one I picked as the default, the behavior remained the same.
This fixed the problem in Eclipse, and showed me the error that I was getting from running the same unit tests from the command line. Looked like some kind of autoloader problem. After lots of trial and error, I decided to get back to basics and build the same class and test class in a simple setup without any TYPO3 extras. By doing this I figured out a few things I had done incorrectly with the bootstrap and phpunit.xml file, for instance, forgetting the "includePath" tag for where to find the classes corresponding to my test classes (doh!).
Going back to the TYPO3 PHPUnit test files in Eclipse, the autoloading problem was still the same. I finally decided, with less than two hours left until the day is over, to continue going through the tutorial from "Reliable Extensions", while building out the test classes in my simple environment. At least then I will get some practice with assertions and the basics of test-driven development. At the same time, I will continue developing them (as they should be developed) in my TYPO3 environment without even bothering to run them.
Today I spent the whole day trying to get something to work, that did not work out in the end - and I have four, dull handwritten pages recording all the steps I took and the logic I used. It made me aware of the fact that my first strategy in trying to fix a problem is trial-and-error. When my frusteration gets too great, I take a break and then get back to basics, to reset my mind and get it unknotted. Finally, if I think that it's really, really not going to work, I stop hammering myself in the head with it and do something similar that I know DOES work. In this way, I am going to get through this
I can't wait to be able to ask experts about how to solve these problems and get some insight into how they work, what their process is. If anything else, I've learned to be impatiently curious about how to solve all the difficulties I've come across and was not able to solve on my own. TYPO3 remains a challenge.
No comments:
Post a Comment
Play nicely!