Integration Testing Guidelines

Integration tests are testing PetaPoco as a whole (plus minor other situations). Our primary purpose for having integration tests is so that we can ensure the consumer that PetaPoco works as a whole against the supported DB of their choosing. Additionally, it help us know that with each release we haven't introduce bugs within a test coverage. Ultimately a more stable product means happier developers!

Sometimes choosing between integration testing and unit tests isn't so easy see, so these are the PetaPoco guidelines for deciding.

Integration testing if:

You are testing a component to ensure it is working when combined with all other components (PetaPoco as a whole)
Or, you require a real DB to ensure the component works correctly
Or, the bug you're reporting is for a specific DB instance
Or, you can't easily mock/stub and running the test in a live environment is easier

Regarding point 4. Yes we know that mocks/stubs/abstractions/xyz could achieve the same. However, as PetaPoco is about simplicity and we prefer to keep it simple, clean and easily understood.

Adding tests

Generic tests must be easily be run against all supported DBs. Only DB specific tests should be limited to a particular DB type. Please refer to existing integration tests to see how we achieve this goal.

When adding a model (AKA entity/poco) ensure corresponding DDL scripts have been modified to include the new model.

Solution layout

Test file layout

File name:

Name of the test must describe what is being tested. For example, SqliteDeleteTests tests Sqlite deleting operations.

Test name:

The test name must be in the format of {this method/operation}_{this/theses conditions}_{expected result}. For example, Delete_GivenPoco_ShouldDeletePoco and Update_GivenPocoUpdateSql_ShouldUpdateThePoco. The only exception here is confirming an exception is thrown. For example Delete_GivenDbGoesAway_Throws.