The assumption is that we're working on a large legacy Java codebase - with active ongoing development.

I had a team member say:

We should use lots of smaller JUnit tests that are focused on one class - because the fast feedback and ease of maintanence gives us value.

I had another team member say:

We should focus on integrating several classes (and external files) in integration tests, because the bugs happen at the integration points between classes - and this is how we'll deliver business value. This is because the more you mock out, the less value your unit tests will have.

I'm trying to adjudicate this discussion and drive some consensus. I'm looking for a way to get people to agree on the tradeoffs between shorter highly mocked JUnit tests, and slightly more integrated integration tests. This is so we can all focus on one particular goal.

My question is: What is the method to articulate the tradeoffs between short-fast mocked JUnit tests and slower Integration tests?


Stop, they're both right.

Every class deserves unit tests that exercise every line of code.

Every integration point deserves to be exercised in an integration test.

The only trade off is when you use them. Integration tests don't help you develop the inner workings of the class. Unit tests do. Unit tests don't help you configure the interconnections between components. Integration tests do.

What does that mean? That if you're running integration tests when refactoring the inner workings, you're wasting time. Only run integration tests when you need to be sure that you're properly integrated. Say like, before you check in code to a branch shared by others. It's a handy way to be sure you didn't break the build.

Unit tests should run very fast. Fast enough that you don't think twice about running them every time you compile. You only need to run the ones that are for the class you're working on.

Integration tests should be automated. They should exercise multiple components to prove that they work together. Integration tests are most important to run when configuration changes have been made.

If your team is thinking that they have to choose to develop one or the other they simply don't understand what these kinds of tests are for. They are not at all exclusive. Just very different.

  • Seriously, every class deserve unit test ? Not unless we all code only for Nasa. – Ajeet Ganga Dec 20 '16 at 5:57
  • 2
    @Ajeet, every method in every class deserves multiple unit tests.For everyone; not just Nasa. – David Arno Dec 20 '16 at 6:47
  • 1
    I cringe every time, I see an answer that claims to be universally applicable. – Ajeet Ganga Dec 20 '16 at 8:51
  • @Ajeet - It's a matter of how much risk you want to take. Hearing someone claim this class is trivial and will never change, so it doesn't need to have a test, can be cringe-worthy as well. – JeffO Dec 20 '16 at 12:18
  • This answer is offered without any warranty of universal applicability. Your results may vary by universe. For external use only. Offer void where void. Do not fold, spindle, or mutilate. – candied_orange Dec 21 '16 at 1:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.