Testing code for correctness is important. Whether you do strict TDD or not, tests are really the only way a project can scale in size beyond a point where every team member can reasonably keep all the code knowledge loaded in their brains at once. After that point, tests are imperative in order to ensure future modifications don't break old logic (that or you're burning lots of resources doing the same thing manually).

The majority of people understand what I've stated above -- not much to argue with there. However, without much of a CS background, there is a lot open to interpretation. Naively, tests are likely to simply mean code that runs other code. While this is true, it doesn't paint the entire picture. Without much concern for proper testing, in my experience, people will tend to generate a bunch of integration or functional tests when asked to write unit tests.

Whether you aren't privy to testing nuances, or whether you simply choose to ignore them (in the interest of time or because you don't like testing), the result is the same. You get a project with a bunch of "confused tests", or tests that don't really respect the line between unit, functional, and integration styles of testing. In other words, you get tests that don't have a clear purpose other than to exercise as much code as possible. This is frustrating because it becomes increasingly cumbersome to parse the result of those tests for meaningful information.

  • Did the tests fail because my remote server is down, or is my logic incorrect?
  • Why is this "unit" test failing when I swap [un]related system component x for component y?

And so on. How can you illustrate this distinction in a way that someone with a more engineering/get-it-done mindset can identify with? In essence, how do you make people care about the distinction?

Indeed, at a recent Android testing meetup at Twitter, the team asserted that full blown testing of software is a project in-and-of itself. And projects require resources. You can't just slip testing in on the side and not think much about it. Resources must be allocated and developers must take it seriously.

That's a good start, but we can't just throw retrospective resources and attention at code that's already been written. I'm curious, what approaches work to remedy a confused test landscape, and how you can prevent confused tests from happening in the first place?

marked as duplicate by mattnz, Robert Harvey, gbjbaanb, gnat, Kilian Foth May 9 '14 at 6:07

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • what is "confused tests"? I have never heard term like that – gnat May 8 '14 at 21:32
  • tl; dr: tests that are partly unit, partly functional which in turn yield unclear results. – David Cowden May 8 '14 at 21:34
  • @gnat I don't think it's a dupe because the question you linked is talking about testing in general. This question operates off the assumption that you already agree testing is important. (My first paragraph tries to address this.) – David Cowden May 8 '14 at 22:02
  • 1
  • 2
    @psr I've read that meta discussion before. I think I've provided enough context and direction so that this question does not fall in the "how do I explain ram to a 5 year old" bucket. If people can't actually read the question because there's too much text, then I'm doomed forever anyway so do what you want with the question. However, with all due respect, I believe I'm very clearly asking what to do when you've got tests with tangled roles. Certainly someone out there has been in a similar situation and advice as to what worked/didn't or would be helpful to me. – David Cowden May 8 '14 at 23:32