Download the PHP package laracasts/testdummy without Composer
On this page you can find all versions of the php package laracasts/testdummy. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download laracasts/testdummy
More information about laracasts/testdummy
Files in laracasts/testdummy
Informations about the package testdummy
TestDummy
TestDummy makes the process of preparing factories (dummy data) for your integration tests as easy as possible. As easy as...
Build a Post model with dummy attributes.
If we then do $post->toArray()
, this might return:
Build a post, but override the default title.
Again, when cast to an array...
Build an array of attributes for the model.
The difference between build()
and attributesFor()
is that the former will return an instance of the given model type (such as Post
). The latter will simply return an array of the generated attributes, which can be useful in some situations.
Build and persist a song entity.
Create and persist a comment three times.
In effect, this will give you three rows in your comments
table. If that table has relationships (such as an owning Post), those related rows will be created with dummy data as well.
Usage
Step 1: Install
Pull this package in through Composer, just like any other package.
Step 2: Create a Factories File
TestDummy isn't magic. You need to describe the type of data that should be generated.
Within a tests/factories
directory, you may create any number of PHP files that will automatically be
loaded by TestDummy. Why don't you start with a generic tests/factories/factories.php
file.
Each factory file you create will automatically have access to two variables:
$factory
$faker
$factory
is the function that you'll use to define new sets of data, such as the makeup of a Post or Album.
Think of this as your definition for any future generated albums - like when you do this:
Faker
You probably won't want to hardcode strings for your various factories. It would be easier and faster to use random data. TestDummy pulls in the excellent Faker library to assist with this.
In fact, any files in your tests/factories/
directory will automatically have access to a $faker
object that you may use. Here's an example:
Now, each time you generate a new comment, the body
field will be set to a random sentence. Refer to the Faker documentation for a massive list of available fakes.
Relationships
If you wish, TestDummy can automatically generate your relationship models, as well. You just need to let TestDummy know the type of its associated model. TestDummy will then automatically build and save that relationship for you!
Using the Comment
example from above, it stands to reason that a comment belongs to a user, right? Let's set that up:
That's it! Notice the special syntax here: "factory:", followed by the name of the associated class/model.
To illustrate this with one more example, if a song belongs to an album, and an album belongs to an artist, then we can easily represent this:
So here's the cool thing: this will all work recursively. In translation, if you do...
...then not only will TestDummy build and persist a song to the database, but it'll also do the same for the related album, and its related artist. Nifty!
Custom Factories
So far, you've learned how to generate data, using the name of the class, like App\User
. However, sometimes, you'll want to define multiple types of users for the purposes of testing.
While it's true that you can use overrides, like this:
...if this is something that you'll be doing often, create a custom factory, like so:
In the code snippet above, you're already familiar with the first example. For the second one, notice that we've added a "short name", or identifier for this special type of user factory. Now, whenever you want to quickly generate an admin user, you may do:
Defining with Closures
Alternatively, you may pass a closure as the second argument to the $factory
method. This can be useful for situations where you need a bit more control over the values that you assign to each attribute. Here's an example:
Of course, just be sure to return an array from this closure. If you don't, an exception will be thrown.
Step 3: Setup
When testing against a database, it's recommended that each test works with the exact same database environment and structure. That way, you can protect yourself against false positives. An SQLite database (maybe even one in memory) is a good choice in these cases.
Or, if a DB in memory isn't possible, to save a bit of time, a helper Laracasts\TestDummy\DbTestCase
class is included with this package. If you extend it, before each test, your test DB will be migrated (if necessary), and all DB modifications will be channelled through a transaction, and then rolled back on tearDown
. This will give you a speed boost, and ensure that all tests start with the same database structure.
Step 4: Write Your Tests
You're all set to go now. Start testing! Here's some code to get you started. Assuming that you have a Post
and Comment
model created...
This will create and save both a Comment
, as well as a Post
record to the database.
Or, maybe you need to write a test to ensure that, if you have three songs with their respective lengths, when you call a getTotalLength
method on the owning Album
model, it will return the correct value. That's easy!
Now, of course, just make sure that you've registered a definition for a Song
and Album
in one of your factory files, and you're good to go!
FAQ
How do I specify a different factories folder?
Easy. Before your tests run, add:
Now, TestDummy will look for your registered factories in the app/tests/factories
folder.
I want to control how my models are built and saved...
Okay, just create your own implementation of Laracasts\TestDummy\IsPersistable
. This contract is composed of a few methods that you'll need to implement.
Once you have your implementation, before your tests run, add:
And that's it! Now, whenever you generate and save an entity, TestDummy will reference your custom implementation.
All versions of testdummy with dependencies
illuminate/support Version ~4.0|~5.0|~6.0|~7.0|~8.0
fzaninotto/faker Version ~1.4