What Not to Unit Test

I need to start this by saying that TDD is a very powerful technique that helps.

This is a discussion of the areas not to test.

Don’t fully test a library. Do have a test that the library does what you need.

Don’t build integration tests when you are unsure about the specific implementation ( especially if the setup becomes excessive). Add the tests on the second feature.

When integrating with 3rd party APIs you may get more value instrumenting well and seeing hoe it behaves in production. This is the source of the “don’t mock what you don’t control” rule. Vendors rarely provide an accurate test environment. REPLs are the best way to experiment with them.

If you have complex logic (more than one if statement or a trivial reduce) then write tests for that. They will be easy to write now and will be valuable as things become more complicated.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s