igorw wrote:Might want to make the autoloader available in all tests, moving that stuff to framework.php.
Please look at this.
bantu wrote:Most of the commits do not contain a ticket ID, so one has to go through those anyway (better sooner than later). Also, develop should probably have never been merged back into the feature-branch, the feature-branch should have been rebased because that is much cleaner. Maybe you can fix both things at the same time.
Working on this.
nn- wrote:The basic tests are all positive, from Igor's earlier comment I am led to believe that a negative test is required - that cron manager should not return a task that is not ready to run.
Yes, that would be good. IMO the current tests make too many assumptions about the environment. You are just testing if the cron manager is returning any tasks in most cases. It would be better to give the cron manager some kind of mock tasks. So we can test different scenarios. What happens when a task is runnable, what when it should run. Then combinations and more than one task. And parametrized tasks. When testing the cron manager, we should not make assumptions about the task implementations (here's where dependency injection comes in handy).
The other thing would be testing the actual task implementations. I believe PHPUnit provides a way to set globals that are reset after every test case (possibly even automatically). That may be useful when testing things like tidy_cache, allowing you to create a "fake" mock cache object that does nothing, and you can just check if it run or not (take a look at class_loader_test, it uses a cache mock).
I hope that gives you some more ideas for testing.