-
Notifications
You must be signed in to change notification settings - Fork 600
Unit Testing Guidelines
Unit tests are testing a component within PetaPoco or two components interacting with each other (careful here as it might be an integration test you're after). Our primary purpose for having unit tests is so that we can ensure the consumer that we take pride and care with our code and actively not take steps to break functionality or introduce bugs. Additionally, it helps us know that with each release we haven't introduce bugs within the test coverage. Ultimately, this leads to a more stable product and means happier developers!
Sometimes choosing between integration testing and unit tests isn't so easy see, so these are the PetaPoco guidelines for deciding.
Unit testing if:
- You are testing a component to ensure it is working as designed
- Or, you are testing component A's interactions with component B in a specific environment
- Or, the integration testing guidelines lead to you believe a unit test is more appropriate
A test should reside in the similar namespace as the component you're testing. For example PetaPoco.Core.Sql => PetaPoco.Tests.Unit.Core.SqlTests.
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
.
- 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!
PetaPoco is proudly maintained by the Collaborating Platypus group and originally the brainchild of Brad Robinson