I'm having trouble doing integration testing. I test my database functions. My web application does not use any framework database connection and I am not able to do tests without messing up my database.
I would like to know how to test without inserting data into the database and changing the information in my application. What functions and classes should I use?
I'm just finding solutions to hibernate.
You should use one database for production and one for your tests. Put the name of the database in question to be used in a configuration file, in order 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 URL of the database, used driver, username, password, etc.
Once you start your tests, you invoke some method that is responsible for creating or cleaning the database (you can use the @Before or @BeforeClass annotations if you are using JUnit 4 or @BeforeEach or @BeforeAll if you are using JUnit 5). To do this, simply run a script containing all the%% instructions required to destroy any existing previous database, and then run the DROP TABLE , CREATE TABLE , ALTER TABLE , and INSERT statements set needed to re-create and repopulate the database. You can also choose to use an in-memory database for testing, which improves performance and simplifies the re-creation process. However, these approaches can introduce some problems:
Differences between the database in physical and in-memory files can compromise the tests.
If you use a physical database for testing, the process of destroying and rebuilding the database can be quite costly (it can be costly, even in some cases with a database in memory).
Because of these issues, you may want to try to use the dirty database between one test and another if possible (just never use the production database), cleaning up the existing database before the first test, and using -o to the last. On the other hand, this procedure of reusing the dirty database also has its problem:
This loss of insulation is the price to pay for not having the tests so costly in terms of performance. And therefore, if used, it should be done with care and in a planned way, so as not to end up compromising the quality of the tests.
Therefore, to ensure the best balance between performance, independence of tests, and fidelity to the physical database, you may want to separate the tests into categories. Those that can be run in memory and those that need the database in physical files. Those that can run on dirty bases by previous tests and those that need the base zeroed. It's easier to deal with all these different cases when using multiple different test databases.
Usually it is recommended to use an in-memory bank to perform the tests. The bank will be created and loaded just 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.
