Test without "fouling" (adding data) the database

Asked

Viewed 567 times

4

I am having trouble doing integration testing. I test my database functions. My web application does not use any framework database connection and I am unable to do tests without fouling my database.

He wanted to know how to do tests without me entering data in the database and changing the information of my application. Which functions and classes should I use?

I’m just finding solutions for Ibernate.

  • what would be "dirty the comic?

  • Soiling would be entering data into the database by the time I test

  • 3

    Why don’t you use a test bench?

  • or exports it to a backup file, and returns later?

  • Because my application will grow a lot. The problem is not taking the test, which is something I’m getting.

  • You are doing manual or automated testing?

  • And if you deleted the data entered in the tests?

  • @helciodasilva is a good option. It is the best q I using. But of any affects my bank, in the fact of generating many id’s that in the future will be erased and also when my application starts running, not legal I run straight the bank. Something that simulates itself he would be the one who would most attend me

Show 3 more comments

2 answers

1


You must use a database for production and another for your tests. Put the name of the database in question to be used in a configuration file, so as to have a configuration file for your production base and one for your tests. It is also possible to put in the configuration file, the database URL, driver used, username, password, etc.

Once this is done, before you start your tests, you invoke some method that is responsible for creating or cleaning the database (you can use the annotations @Before or @BeforeClass if using Junit 4 or @BeforeEach or @BeforeAll if you are using Junit 5). For this, just run some script containing all the instructions DROP TABLE necessary to destroy any existing previous database and then run the instruction set CREATE TABLE, ALTER TABLE, INSERT and UPDATE necessary to recreate and repopulate the database. You can also choose to use a database in memory for the tests, which improves performance and simplifies the process of recreating them. However, these approaches may introduce some problems:

  • Differences between the database in physical files and in memory may compromise the tests.

  • If you use a physical database for testing, the process of destroying and recreating the database can be quite costly (it can be costly even in some cases with a database in memory).

Because of these problems, you should try to use the dirty database between one test and another if possible (just never use the production database), cleaning the existing database before the first test and using it until the last test. On the other hand, this procedure of reusing the dirty database also has its problem:

  • The independence and isolation between your tests can be compromised, causing one test to interfere with the other.

This loss of isolation is the price to pay for not having the tests so costly in terms of performance. And therefore, if used, it should be done carefully and in a planned way, not to end up compromising the quality of the tests.

Therefore, to ensure the best balance between performance, test independence and fidelity with the physical database, it is convenient to separate the tests into categories. Those that can be run in memory and those that need the database in physical files. Those who can run on dirty bases by previous tests and those who need the base zeroed. It is easier to deal with all these different cases by using multiple different test bases.

0

It is usually recommended to use a memory bank to carry out the tests. The bank will be created and loaded only to test, at the end of the tests the bank will be destroyed.

You can use the normal bank as well, as long as it is a bank created specifically for testing. You should not use the same database to test and run the application.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.