Unit Testing Guidelines

Unit tests ensure developers and consumers alike that we take pride in our code and take steps to avoid breaking existing functionality or introducing new bugs. These tests confirm that each unit/component performs as expected, or that two components interact with each other correctly. We believe broad test coverage leads to a more stable product and happier developers!

Where multiple components are concerned one must make certain they do not actually require an integration test. Sometimes choosing between integration testing and unit tests isn't so easily seen, so these are the PetaPoco guidelines for deciding.

Unit testing if:

1. You are testing a component to ensure it is working as designed
2. Or, you are testing component A's interactions with component B in a specific environment
3. Or, the integration testing guidelines lead to you believe a unit test is more appropriate

Adding tests

A test should reside in a similar namespace as the component you're testing. For example PetaPoco.Core.Sql => PetaPoco.Tests.Unit.Core.SqlTests.

Test file layout

File name:

The name of the file must be {Component name}Tests. For example, SqlTests and ConventionMapperTests.

Test name:

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

Questions

• Can I use another test framework, like Nunit? No!
• Can I implement tests in my own way? No!
• Should I keep it consistent? Yes!
• Do I have to write unit/integration tests? Yes!