[L5] How to unit test Eloquent models in your workbenches

Migrations, part of the same problem...

I forgot to mention, that when working with Eloquent models, migrations are also a part of the challenge, when working inside a workbench-package. By this I means, you are required to migrate from specific packages, in order to test specific models. While this can be done manually, via artisan, from the top-level, its too time consuming. This is also something that I wish / must be able to do automatically, from the unit-tests' setup / before / config methods.

Nevertheless, having access to Laravel's core features is still a prerequisite. One which I still have not yet found a good solution for.

Hi, fundamentally you should not test eloquent model itself at all. Eloquent models have their own tests. If you want to test some particular requests to your database via eloquent models or query builder or plain sql, you should wrap those requests to some abstraction (e.g. repositories) and then you should use functional/intergartional tests to those abstractions (repository) methods.

And if you want to write functional/integrational tests for workbench package you should use package you mentioned "orchestral/testbench"

This is how I've usually done it:

https://github.com/adamwathan/eloquent-oauth/tree/master/tests

Look at FunctionalTestCase and IdentityStoreTest. These tests run fine on TravisCI too.

Why I meant by "Eloquent models";

use Illuminate\Database\Eloquent\Model;

class Dog extends Model {
// ... implementation not shown
}

Now, imagine that I added some kind of custom query method, for e.g. finding all dogs that are injured - that method would be nice to be able to test, in a unit-test (my preference), rather than relying only on higher level tests.

Anyways, I ended up re-creating a trait, which I can use with Codeception (or other frameworks), built upon the orchestra/testbench package. Thus far, this works okay - but still a bit confused regarding where it is reading its configuration from, - but guess that's a topic outside this scope. My trait looks like this:

namespace XXXYYYZZ\Testing;

use Orchestra\Testbench\Traits\ClientTrait;
use Orchestra\Testbench\Traits\ApplicationTrait;
use Orchestra\Testbench\Traits\PHPUnitAssertionsTrait;

/**
 * Testing Trait
 *
 * 
 * <b>usage</b>
 * <pre>
 *    1) Use this trait, in your test-case / unit-test... etc
 *    2) Invoke startLaravelApplication() in your setUp()/_before() methods
 *    3) Invoke stopLaravelApplication() in you tearDown() / _after() methods
 * </pre>
 * 
 * <b>NB:</b> This trait assumes that the following package is available:
 * @see https://packagist.org/packages/orchestra/testbench
 */
trait TestingTrait {

    /**
     * Use the traits from Orchestra
     */
    use ApplicationTrait, ClientTrait, PHPUnitAssertionsTrait;

    /**
     * Starts the application and ensures that the "testing"
     * application environment is set
     * 
     * @return void
     */
    public function startLaravelApplication(){
    if(!$this->app){
        $this->refreshApplication();
    }
    }

    /**
     * "Stops" the application and ensures that its flushes its
     * bindings and resolved instances
     * 
     * @return void
     */
    public function stopLaravelApplication(){
    if($this->app){
        $this->app->flush();
    }
    }

    /**
     * Return instance of the current application
     * 
     * @return \Illuminate\Foundation\Application
     */
    public function getLaravelApplication(){
    return $this->app;
    }

    /**
     * <b>Re-implemented from Orchestra\Testbench\TestCase</b>
     * 
     * Define environment setup.
     *
     * @param \Illuminate\Foundation\Application $app
     * @return void
     */
    protected function getEnvironmentSetUp($app) {
    // Define your environment setup.
    }
}

I don't think that your aim is to test if query is built correctly, is it? If so then you could easily test it with unit tests, however you will need to pull one of illuminate packages as dependency which has query builder.

Well, since I am new at using Laravel, there are many things I have yet to learn. Normally, when I created some kind of Model, I do spend a bit of time writing tests, ensuring my custom queries are able to fetch / execute what their are supposed to. So, yes... I suppose that is among the things I wish to achieve.

Nevertheless, thus far, I have had quite some trouble getting everything from Facades to other Laravel specific code to run, inside my tests, while situated inside a workbench-package.

In other words, writing unit-tests (regardless of which kind) is very easy, when located at the application level (the root, if you will), especially when you simple extend the Functional/TestCase class. But when you are inside a package, then it becomes frustrating that you cannot access certain Laravel specific code, such Facades. As an example;

// Located inside e.g. MyVendorName/MyPackage/tests/MyTest

public function testArtisanMigration(){
         Artisan:call('migrate'); // --> Will fail, because Artisan is unknown

         // ... Assertion(s) not shown
}

Supposed that I do have a "use" statement, which the autoloader can resolve for the Artisan-package/class, I still run into trouble, because I doesn't know about the "call" method!

In addition to this, imagine that you have a "database.php" configuration, inside your testing environment folder. In order for that specific configuration to be read, I have no clue what I am supposed to do, e.g. if I need to run tests inside a specific database, when inside a package.

The previously mentioned package from Orchestra did help solve many of my issues - yet I do find it overkill that the entire Laravel Framework needs to be included inside every package, in which I have Models to be tested - or other Laravel depended code.

Anyways, thanks for all the replies, ... any thoughts about this subject are welcome, and will be taken carefully under advisement :)