Bugzilla – Bug 5683
Unit Tests: Can't call method "error" on an undefined value at Slim/Utils/Log.pm
Last modified: 2008-04-01 16:55:38 UTC
System Info: IBM Think Centre with Ubuntu installed Steps to Reproduce: 1. Download all the code from svn. 2. Go to the "tests" directory. 3. Start the white box tests suite by typing "prove -r t/". 4. While the 00use.t script is running, notice the following complain: Failed test 'use Slim::Plugin::InfoBrowser::Plugin;' # in t/00use.t at line 79. # in t/00use.t at line 79. # Tried to use 'Slim::Plugin::InfoBrowser::Plugin'. # Error: Can't call method "error" on an undefined value at /home/testpc03adm/trunk/server/Slim/Utils/Log.pm line 288.
the log class isn't initialised by the test framework. not sure how to do that, but I wasn't even aware the test framework was ever in a working state :)
Hi, KDF, I believe the framework is working. When I run prove -r t/ within the tests directory, 54% of the tests would pass. Is there any other commands or ways to run these tests. The tests seem to be very useful.
They are useful, just that it hasn't been given much time and effort in maintenance. I've never seen them work fully, and just looking over the test routines, looks like there is a lot of library loading and configuration that is out of date. Many of the errors that it currently reports (like the missing error method, and missing modules) is due to a config problem. It is not loading up the logging API, nor does it seem to be loading the CPAN or lib modules when it should. However, it would be nice to have it as a focus task at some point. Admittedly, due to never having seen it work, I've not made myself familiar with the tests. It may be that the major faults are a simple fix to make it load the proper frameworks. Andy may know how much effort would be required.
When I first ran them, the passing rate was 37%. Many of the tests simply did not run at all. So far, I managed to make 54% of them to pass, and am getting a good handle on why some of them are failing. I am trying to have the whole thing running. Thanks for you help.
sounds good. However, it would be really great if you can group them. Maybe by test or even just as "test framework" in one big bug. The dumps are easy enough for anyone to see based on "prove all" so it's not like we need something for each item, at least not until there is some understanding that the test framework is expected to be working. On my setup, I had to install a large number of outside modules just to get started. It not what I'd call ready. However, it might be good to have a small number that can be targetted, such as "pod validation", "use validation", " metadata validation" etc.
I actually stumbled on the cause of this problem today. The Log init code uses logBacktrace for errors, but the logging code isn't set up so the race condition causes this error.
reassigning bug to Wallace from unassigned
Let's look at this bug post 7.0.1.