Every project that has a database has a dilemma when it comes to how to test database-dependent code. There are several options (not mutually exclusive):
Use mocks. Only use unit tests and mock the data-access layer, assuming the DAO-to-database communication works. Use an embedded database that each test starts and shuts down. This can also be viewed as unit testing. Use a real database deployed somewhere (either locally or on a test environment). The hard part is making sure it's always in a clean state. Use end-to-end/functional tests/BDD/UI tests after deploying the application on a test server (which has a proper database).None of the above is without problems. Unit tests with mocked DAOs can't really test more complex interactions that rely on a database state. Embedded databases are not always available (for example, if you are using a non-relational database or if you rely on RDBMS-specific functionality, HSQLDB won't do), or they can be slow to start. This means your tests may take too long in supporting. A real database installation complicates setup, and keeping it clean is not always easy. The coverage of end-to-end tests can't be easily measured and they don't necessarily cover all the edge cases, as they are harder to maintain than unit and integration tests.
No comments:
Post a Comment