Pooling (Singleton) Objects Against Connection Pools

The simplest change to make your class unit testable is to

1. (extract the creation code into a new (virtual) method - you already have this)
2. subclass the tested class, overriding the creation method to create a suitable mock object instead of the real one
3. write your unit tests :-)

Of course, this is not very nice. But it allows you to cover the class with unit tests, after which you can start refactoring towards the ideal design, without fear of breaking code with deeper changes.

Obligatory reference: Working Effectively with Legacy Code.

About that ideal design it is hard to tell much though, since your example lacks details and context. If you tell us more about what you are aiming to test and what is the role of the tested class, we might be able to help more.

The fact that it looks odd to you may be a sign that it shouldn't be static. You can instead encapsulate the loader methods into a non-static class which also takes the database object in the constructor. To me this creates a more natural form of dependency injection (same way you did the Job class). The object asks for everything it needs to get the job done in the constructor and it doesn't have to be passed into each method.

class Loader {
    protected $objDb;

    public function __construct($objDb) {
        $this->objDb = $objDb;
    }

    public function LoadArrayByUserId($intUserId) {
    }

    public function LoadArrayByProjectId($intProjectId) {
    }
 }