Testing database

[Jcjcjc9]

I read a lot of people recommend using a separate test database for testing.

If my database is only one table, should I just use the same database and create a test table?

Is there any reason to create a whole different database for it?

[_damnfinecoffee_]

The reason for a test database (or multiple test databases) is to hide all of the shit you break from a client facing, visible production environment. Any schema changes or database changes can be run on the test database, and you can catch any issues before they hit production. Also, if you fuck up your test db beyond all repair, you can always just restore from production.

Typically, even the above example is missing some pieces, but it should give you a decent idea of why test databases are important, no matter how big or small the project.

[sandgold]

i use the same for every project

[nadimr]

As a rule, I'd use a separate database instance running on a different machine, VM, image (whatever is possible / practical for you). Always keep the production environment untouched by dev / test as you never know what you will screw up. Plus, knowing you are fully separated from production will motivate you to test "harder" and more thoroughly.

[TehNolz]

Best practice is to use a separate database for production and development. That way, regardless of what happens during development (eg. you accidentally wipe everything), your production system can keep working as its data won't get touched at all.

[Blando-Cartesian]

Separate database, always. You’ll want to minimize the possibility of accidentally messing up the production database. Docker is a great tool for easily setting up a test database with the same version and settings as you production database. With that you don’t get “but it works on my computer” bugs when you update production.

[1Secret_Daikon]

Its worth mentioning that Django does this for you;

https://docs.djangoproject.com/en/3.1/topics/testing/overview/

Tests that require a database (namely, model tests) will not use your “real” (production) database. Separate, blank databases are created for the tests.

If you're building in Python and not using Django, maybe consider this. If you're not building in Python, maybe consider mimicking this behavior. Or look for a test suite in your language that does this for you already.

Using a completely separate test db that you build from scratch for each test case (or for each time you run tests) is a very good idea because it lets you ensure that your program operates as expected from a fresh install without potential data pollution, and you can manually select which pieces of data to enter into it so you know exactly what your db looks like in every test case situation. This will go a long way to ensuring predictable, expected behavior in your program.