Integration testing and unit testing
Also known as, “An exercise in Twitter opinionating”:
Sitting in a meeting, I heard one of the other meeting participants say, “You should do your integration testing before your unit testing in your code.”
Now, I wasn’t (and I’m still not) sure I agree with this or not, and when in doubt, I like to get data points. Twitter to the rescue!
The responses that came back were fascinating, and all over the map:
Why? Disagree, unless I'm missing something => RT @tedneward: OH: "You should do your integration testing before your unit testing."
@tedneward disagree! How could an unstable code (not unit tested)be ready for integration testing
@tedneward Write acceptance tests, so we're all on the same page, then use TDD to get components in place until acceptance tests pass.
@tedneward There is value on an agile team for starting with automated acceptance tests, as a stopping function for development effort.
@tedneward mostly agree integration first helps to focus on feature, not losing in details
@tedneward Depends on the intent of the integration testing. If it's to find gaps in the feature set, maybe. Otherwise, disagree.
@tedneward disagree. The order depends on what you're creating.
@tedneward I continually intermix them; can't say I care a lot about the distinction either in most cases
@tedneward in the sense that you may want to have some of the integration work done before you write the internals, yes.
My next thought was “how do I capture this for further discussion”, so here we go.
Couple of thoughts that occur to me as I read through the responses:
- Are acceptance tests the same as integration tests?
- Are either of these at the same level of scope as unit tests?
- Does it make a difference which order you approach them?
Love to hear your thoughts.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)