I'm trying to contribute to the unit testing, I'm making some good progress. I just wanted to ask a question about how something "should" be done.
I'm currently writing tests for the autoloader class... Now, if I want to test if properties were set correctly, I would have to either check if values were set on the class properties... or use another class to see if it was loaded and setup properly.
Obviously, we don't want to add extra methods to the classes to facilitate testing (I think).
Here's the question:
Would you rather I create a temporary extension class in the test file that extends the class we are testing so I can add methods to access protected properties. Or would it be better to use the class as intended and check for its functionality based on information from other classes being utilized as a result.
Sorry if this is confusing, trying to explain it as best I can. It seems the former would be a better solution as it encapsulates the functionality of class we're testing and doesn't depend on any other classes to be run. I see that being a problem in the future as the framework changes and progresses...
Let me know.
Ideally, you would only test the method conditions (input/output), everything in the method should be a black box as far as the calling code is concerned.
Same is true for protected or private properties, they are not visible and/or accessable by the calling code.
I understand what you're on about, it's something I've been thinking about as well. If you have methods whos primary job is to setup internal data structures that are not directly accessable. I think the key here is to see which methods use these structures, and based on that information create test sets that would test all possible scenario's.
Perhaps a little abstract thinking is in order, I'll see what I can come up with. Makes sense, your point about "black box"ing the methods that are not accessible outside of the callable code... I guess I can try and just think of the classes uses and test each scenario...
Donate
