Is the test database cleared after each test?

[krfg]

Some of my tests would not pass if the test database was not cleared after the previous tests.
For instance my application, based on the Michael Hartl's tutorial, gives users the opportunity to create an association between two users.
The web interface is configured to use or not use Ajax.
There are usually two tests, one for Ajax and the other for standard html requests, and both of them check that the association between the same two users user1 and user2 was created by counting the number of user1 relationships, that should be increased by 1. Now user1 could not create twice the same association with user2, unless that association was cleared after the first test. Is that so?
If this is Rails behaviour, which I only guess is such because I could not find documentation about it, I would rely on this for all my future tests.
In particular I would like to test a background job that populates my database by counting that the number of saved records (100) is correct as expected.
If the database is cleared after this test I could re run the test and I would still count 100 records.
If the database is not cleared, the second time I run the test I would count 200 records, so the test would fail.

[Dave Aronson]

On Fri, Dec 2, 2016 at 11:57 AM, 'krfg' via Ruby on Rails: Talk
<rubyonra...@googlegroups.com> wrote:

> Some of my tests would not pass if the test database was not cleared after
> the previous tests.

The important thing is that every test start from a *known state*.
The easiest state to achieve and reason about, is empty. It also
forces you to be more explicit within your tests (or their
setup/before blocks) about any records you're adding in support of the
test.

But, if you want to start from a known *populated* state, that's a
pretty common approach too.

Either way, though, you need to clean up any changes each test makes.
With a populated start state, you can do each test in a transaction
and roll it back, which assumes you're using a DBMS that supports
that. With an empty state, you can do that, *or* truncate the tables,
or various other options.

-Dave

--
Dave Aronson, consulting software developer of Codosaur.us,
PullRequestRoulette.com, Blog.Codosaur.us, and Dare2XL.com.

[krfg]

On Friday, December 2, 2016 at 6:45:12 PM UTC+1, Dave Aronson wrote:

The important thing is that every test start from a *known state*.

The easiest state to achieve and reason about, is empty.

And what is Rails' default behaviour?
I only guess that it empties all tables after each test, but this is only my guess.

[Dave Aronson]

I'm not sure but I think it rolls back changes (i.e., the transaction
each test is wrapped in) after each test. Or that may be dependent on
what db and/or test framework you're using; I don't think it's even
possible with SQLite, but I usually use PostgreSQL. Anyway, I've
usually used the database-cleaner gem
(https://github.com/DatabaseCleaner/database_cleaner) rather than rely
on whatever Rails chooses to do. Check it out; there may be a
configuration that meets your needs. Avdi Grimm also wrote a good
blog post on it long ago that I remember finding very helpful.

[krfg]

I will have a look at database_cleaner.
Many thanks for your suggestion.

[Colin Law]

On 2 December 2016 at 16:57, 'krfg' via Ruby on Rails: Talk

The default is that the database will be rolled back between tests. If
you look in test.log you will the rollbacks happening.

Colin

>
> --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Talk" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rubyonrails-ta...@googlegroups.com.
> To post to this group, send email to rubyonra...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rubyonrails-talk/8ad94737-79e0-46d7-ba7c-a616b3e4dc08%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[krfg]

On Friday, December 2, 2016 at 10:45:45 PM UTC+1, Colin Law wrote:

The default is that the database will be rolled back between tests. If
you look in test.log you will the rollbacks happening.

This is coherent with a useful stackoverflow topic about the teardown method