Integration testing and unit testing
Join the DZone community and get the full member experience.Join For Free
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.
Published at DZone with permission of Ted Neward, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.