I love TDD and Unit Testing. That said, there are times and places where Integration Testing is more appropriate. In this series of posts, I’m going to explore patterns (and anti-patterns) of integration testing and try to identify when each is appropriate.

First off, what’s an integration test? The loosest definition I can come up with is that an integration test involves either (1) access to out of process resources like databases or file systems or (2) exercises several parts of a larger system working together. For the most part, I’m going to focus on scenario 1.

In no particular order, here’s what I plan on blogging about in this series:

  • Enforce your conventions!
  • Limit your commits
  • Multiple asserts are OK
  • Set up the data as infrequently as possible
  • Don’t test shite that should be tested in a faster test
  • This shite still needs to be fast
  • Make your tests like production
  • No, really, this shite needs to be fast!
  • Readability is still damn important

There’s certainly some overlap in that topic list, so I’m sure I’ll cover multiple topics in every post. I’ll be sure to get to all of the topics, though.

Request a Call

Looking for support?

Send Us Your Feedback

Provide us with some information about yourself and we'll be in touch soon. * Required Field