Integration Testing

Question 1

Test Database Approaches

Answer 1

1. Shared Database.

2. Local Database.

Question 2

Shared Database

Answer 2

All Developers share a remote test database on the network.
#1 Oracle DB.

Question 3

Local Database

Answer 3

Each developer has their own copy of the database on their computer.
#1 MySQL.
#2 PostgreSQL.

Question 4

Shared Database Pros

Answer 4

1. Easy Developer setup.
2. 1 Setup for all developers.
3. Production-like software and hardware.
4. Can be managed by DBAs.

Question 5

Shared Database Cons

Answer 5

1. Unreliable.
2. Brittle.
3. No Isolation.
4. Temptation to rely on existing data.

Question 6

Local Database Pros

Answer 6

1. Production-like software.
2. Reliable.
3. Isolation.

Question 7

Local Database Cons

Answer 7

1. Requires developer to act as DBA.
2. RDBMS needs to be installed locally, requiring additional licenses.
3. Hardware is not production-like.
4. Production like data can be difficult
   Inconsistent across machines

Question 8

Embedded Database

Answer 8

An in-memory database server is started and managed by test code and run inside the application.
#1 SQLite.
#2 Firebird SQL.
#3 ScimoreDB.
#4 Oracle Berkley DB.

Question 9

Embedded Database Pros

Answer 9

1. Very reliable.
2. Consistent across machines.
3. Lightweight.
4. Supports Continuous Integration.

Question 10

Embedded Database Cons

Answer 10

1. Software and hardware are not production-like.
2. Can not use proprietary features of an RDBMS.
3. Production-like data can be difficult.

Question 11

Integration Testing

Answer 11

Is a broad category of tests that validate the integration between units of code or code and outside dependencies such as databases or network resources.

Question 12

Integration tests characteristics

Answer 12

1. Use the same tools as unit tests (i.e. JUnit).
2. Usually slower than unit tests.
3. More complex to write and debug.
4. Can have dependencies on outside resources like files or a database.

Question 13

Integration tests should be:

Answer 13

1. Repeatable.
2. Independent.
3. Obvious.

Question 14

Repeatable Integration test

Answer 14

If the test passes/fails on the first execution, it should pass/fail on the second execution if no code has changed.

Question 15

Independent Integration test

Answer 15

A test should be able to be run on its own, independently of other tests, OR together with other tests, and have the same result either way.

Question 16

Obvious Integration test

Answer 16

When a test fails, it should be as obvious as possible why it failed.

Question 17

Integration Tests should NEVER use

Answer 17

Existing data

Question 18

Integration Test Data Source

Answer 18

SingleConnectionDataSource - creates a direct connection without a connection pool, allowing steps to share the connection, and see changes being made by other steps.

Question 19

Integration Test Life Cycle

Answer 19

@BeforeClass - runs once before all tests. Creates the DataSource and enables Transaction Scope (autocommit=false)
@Before - runs before each test for common Arrange steps
@Test - the test
@After - runs after each test. Rollback transaction
@AfterClass - runs once after all tests complete. Destroy the DataSource.