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.
what would be "dirty the comic?
– Pilati
Soiling would be entering data into the database by the time I test
– Victor Henrique
Why don’t you use a test bench?
– Jéf Bueno
or exports it to a backup file, and returns later?
– Pilati
Because my application will grow a lot. The problem is not taking the test, which is something I’m getting.
– Victor Henrique
You are doing manual or automated testing?
– Gabriel Katakura
And if you deleted the data entered in the tests?
– helciodasilva
@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
– Victor Henrique