#PHP unit tests (database)

28 messages · Page 1 of 1 (latest)

hushed matrix
#

Hi there, I have successfully got testing working with endpoints and session, but the next hurdle I have is testing on a database.

I do not want to use sqlite or run any migrations, because I don't have any migrations. I would just like to use the existing database setting and work with that. As it is just local development and no real live data it is absolutely fine for me to add or drop columns.

What is the easiest way to do this? Do I edit the PHPXML file, or the config file, or create a .env.testing file.

This question is EXPLICITLY for Package development ONLY.

jagged gyro
#

Either should work. Depends on whether you want to set the config for everone (xml) or just you (.env.testing)

#

That said, it's not really a good idea. Tests shouldn't depend on whatever happens to be in the DB beforehand.

hushed matrix
crude mulch
hushed matrix
#

Thanks for the info, I'll look at it tomorrow, I mistakenly closed the other thread by accident, but will keep that in mind for the future.

#

Also, I don't know if this is important, but I don't have any migrations.

#

The database is already pre-loaded

crude mulch
#

How would it be pre-loaded for a package..?
If you're using testbench you should set stuff up like an actual app. So create migrations, it doesn't mean you'd publish those migrations. That way you'll have a usable package, people can then clone it, run the test suite (because it creates the DB, it migrates what needs to be migrated). Otherwise you need some sort of existing DB, that's pretty much unusable.

hushed matrix
#

If this helps all I really want to do is something like

{
  $this->assertDatabaseCount('users', 1);
}```
#

And for it to go green 🙂

#

Sadly, the nature of the database doesn't really allow for that, it's too long to explain, but I can't really use migrations, I'm just importing a .sql file

crude mulch
#

It starts to sound more like you don't need to build that as a package then either? Sounds like you're, for whatever reason, extracting application logic to a package..?

hushed matrix
#

Perhaps, but for the time being I'm creating it as a package, anyway I'll let you know tomorrow how I get on.

crude mulch
#

I genuinely don't understand, if you're making a package it should be reusable, it should be testable on its own. If you need to test certain behavior that relies on other data (such as users), you can create migrations, seed data, have model factories, so you can test that. Using fixed that seems like a significant blocking factor tbh.

hushed matrix
#

Here's the thing, maybe I'm wrong here, but the application allows the user to ad hoc, drop and add columns on the fly, where those columns could be any sql type, varchar, longtext, date etc.

So I just assumed a migration that was explicitly stated before hand was unusable?

crude mulch
#

Then how is an SQL file more helpful, that's just as restrictive?

hushed matrix
#

Again, I'm not sure on this, but I import the baseline tables, but within the web app, they have the ability to ad hoc add and drop columns on the fly

crude mulch
#

So what's the difference between creating a baseline with a migration then?
Also, why would you change columns on the fly, or create the ability to do that through the web..? Laravel has migrations for a reason, your app would just break if things change without code changes, without changes to validation etc

#

Not really trying to judge (even though it sounds like a huge security risk), but trying to understand what the goal is, what the use case is. So it would be easier to guide you through testing

hushed matrix
#

Oh no I totally understand and appreciate the help so far, but there is a good reason, in that it uses those new columns as lookups for content creation. It's hard to explain, but it really is only one table that has that particular feature.

crude mulch
#

Yeah but wouldn't that just result in all kinds of other issues, such as not having indexes?

hushed matrix
#

Yes but it isn't meant to be for fast lookups, it is really meant for an easy retrieval for content, I mean I can show you it when its done in private, if you want, but at the moment it is still very much in beta, the only last remaining step I have to do is figure out how to connect to the existing db with PHPunit (within a package environment) and retrieve or push data, then I suppose I may need to test queues and jobs but I haven't got that far yet.

hushed matrix
#

So I've decided to leave 'testing' this for a while and come back to it later, so I can concentrate on the main internals. (it is probably some config setting but is taking too long to find) Thanks to all who has helped.

hushed matrix
#

OK, so after a lot of experimentation, adding anything or removing anything to the phpunit.xml file inside my package directory was having 0 effect !!

What actually changed the database testing settings was to add this to my TestCase.php file

class TestCase extends Orchestra
{
    protected function getPackageProviders($app)
    {
        return [
            BarServiceProvider::class,
        ];
    }

   protected function getEnvironmentSetUp($app)
   {
       // Define testing environment configurations here
       $app['config']->set('database.default', 'mysql');
       $app['config']->set('database.connections.mysql', [
           'driver' => 'mysql',
           'host' => '127.0.0.1', //sometimes localhost works instead of ip
           'port' => '8889',  //mamp mysql port settings
           'database' => 'laravel',
           'username' => 'root',
           'password' => 'root',
           // Other MySQL configurations...
       ]);
   }

}
#

Then I was able to add this as a FeatureTest

 public function test_database()
 {
     $this->assertDatabaseCount('user',1);
 }
#

And finally running vendor/bin/phpunit and all tests are now green!

#

And my PHPunit.xml file reads

<?xml version="1.0" encoding="UTF-8"?>
<phpunit
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     bootstrap="vendor/autoload.php"
     backupGlobals="false"
     colors="true"
     processIsolation="false"
     stopOnFailure="false"
     xsi:noNamespaceSchemaLocation="https://schema.phpunit.de/10.1/phpunit.xsd"
     cacheDirectory=".phpunit.cache"
     backupStaticProperties="false"
>
  <coverage/>
  <testsuites>
    <testsuite name="Unit">
      <directory suffix="Test.php">./tests/Unit</directory>
    </testsuite>
    <testsuite name="Feature">
      <directory suffix="Test.php">./tests/Feature</directory>
    </testsuite>
  </testsuites>
  <php>
    <env name="APP_ENV" value="testing"/>
    <env name="APP_KEY" value="base64:2fl+Ktvkfl+Fuz4Qp/A75G2RTiWVA/ZoKZvp6fiiM10="/>
  </php>
  <source>
    <include>
      <directory suffix=".php">src/</directory>
    </include>
  </source>
</phpunit>