Integration test hell

I think the point he is driving home is that we should be focusing more on comprehensive unit tests rather than comprehensive integration tests. I've started changing how I write my integration tests: They should only be verifying the interactivity of components, rather the expected results of the component.

Let's say that a User Service class (UserService) that calls a User Data Access Object class (UserDAO). The unit tests for UserService should use a mock of UserDao and asserting exact equality with the data and exceptions returned from UserDao properly (-- nothing new here). Your integration tests for UserService should use a real UserDao that is connected database (-- again, nothing new here). However, these types of test should NOT be asserting data and exceptions equality. Rather, these integration tests should just be verifying that some data/exceptions are returned. Integration tests should be testing the seams between the UserService and UserDao components, rather than asserting the equality of the value themselves.

Overally, I recommend watching this talk if you have done lots of unit and integration tests writing and wondering if you are duplicating effort.

Ego (aka About Me)

I am a software developer with about 6 years of experience in various roles such as a university researcher, independent consultant, and enterprise developer.

My criteria for good software code can be reduced to a single axiom: Good code is easily testable code. This is based on my belief that software code are ultimately theories of how a business process should work. And it is well-accepted in the scientific community that good theories are testable theories. So, good code is testable code.

I hate the word "enterprise" even though I use it quite a bit.

This blog is written for the sole purpose of shameless self-promotion. :)