Integration Tests for SQL

[JeremyCaney]

Currently, while we have decent unit tests for much of the core functionality, the actual SqlTopicRepository itself is not subjected to testing—and it would be difficult to mitigate that, given the nature of the dependencies. Integration tests offer an alternative.

Priority

The scope of impact for this is comparatively small compared to e.g., #39. Much of the business logic is already tested via the TopicRepository base class and the SqlDataReader extension methods. And the underlying database logic is tested by the SQL unit tests. Given that, the priority of this might be pretty low.

Performance

The biggest concern with this is performance, as well as the dependency on a database server. As with the SQL unit tests, this may be best handled exclusively on the localhost using a local test database which isn’t run during the CI/CD pipeline, and may even be unloaded during normal operation.

Git Repository

With the SqlTopicRepository, database schema, unit tests, and proposed integration tests, we’re looking at four projects that are closely related to one another, but necessarily loosely coupled from the core library. Does it make sense to separate these out into their own git repository? This makes coordinating versioning harder. But it would be especially useful if e.g., we later introduce another core repository implementation (e.g., MongoTopicRepository).