Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

This was a question I got in an interview. After asking the coding question, the interviewer asked how I would test the function. I answered with writing unit tests and test cases to try to cover every edge case. The follow-up was how much would I test before I stop?

What's the interviewer looking for in these questions? and what are some good answers?


migration rejected from Jun 10 '15 at 23:47

This question came from our site for professional and enthusiast programmers. Votes, comments, and answers are locked due to the question being closed here, but it may be eligible for editing and reopening on the site where it originated.

closed as too broad by gnat, durron597, MichaelT, Ixrec, Snowman Jun 10 '15 at 23:47

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

Stop when the tests cover all the code. In my experience, a large number of production bugs occur in code that was never tested.

However, if there are so many possible paths through the code that covering the code does not give you much confidence, then you may want to refactor the code to improve testability. This could occur if you have a routine with high cyclomatic complexity and a complex internal state.

If you developing test-first, and only add code to fix a broken test, then the tests will automatically cover all the code. Stop when you have a passing test for all known use cases.

Coverage, unfortunately, is one of the poorer metrics I've seen used (not that I've seen any good metrics tbh). – Steve Evers Feb 28 '11 at 21:16
The only thing that code coverage really measures is the percentage of your codebase that has no tests for it. (ie. 80% coverage = 20% of untested code.) – Mason Wheeler Feb 28 '11 at 22:01

You stop when you have "enough." Enough is a business decision, not really a technical one. Depending on your managers and the corporate culture, "enough" might be zero because any time spent writing tests is time "wasted" that should have been spent writing features and getting it out the door (because they miscalculated the time it takes to get it done in the first place and wouldn't you know it, stuff is "late" again).

My preference is to write enough to give me confidence that the code works. Usually that is a couple of edge cases and a sanity check or 2. Whenever bugs get reported, I'll write up a test to duplicate the reported bug and add that to the test suite. In the absence of someone telling me otherwise, these tests get named stuff like "TestBug2078A" where 2078 is the bug number in the reporting system and the subsequent letters indicate that there are several tests to cover the bug report. Named this way, it is blindingly obvious to even the most clueless maintainence coder that they better not comment out this test if their "fix" breaks this test. When you've been working out in "the wild" long enough, you will learn that there is no limit to the dumbness that can happen.

I agree 'enough' is a business decision that depends on whether you are programming a website or space shuttle. Still, the responsibility rests with the programmer to inform the stakeholders of risks. – Garrett Hall Apr 4 '12 at 16:47

Unfortunately, it mostly depends on how your interviewer would answer that question - the closer you are to their worldview, the better your chances are.

I would estimate that most interviewers who understand testing want to make sure that you:

  • Understand that unit testing is more than a chore - it's actually useful.
  • Come up with significantly distinct and meaningful test cases (not just repeating the same paths)
  • Achieve coverage of code
  • Achieve coverage of end cases
  • Take into account the importance of the method. The truth of the matter is that engineers have to apply common sense, and you shouldn't strive for 100% coverage if the cost is prohibitive.
  • Think about explicitly documenting and capturing postconditions and preconditions (e.g., what is the requirement for the caller?)