Is the test database cleared after each test?

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.

On Fri, Dec 2, 2016 at 11:57 AM, 'krfg' via Ruby on Rails: Talk

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

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

On Fri, Dec 2, 2016 at 12:56 PM, 'krfg' via Ruby on Rails: Talk

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.

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 (GitHub - DatabaseCleaner/database_cleaner: Strategies for cleaning databases in Ruby. Can be used to ensure a clean state for testing.) 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.

-Dave

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

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

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.

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

Colin

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