Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
add comment

migrated from stackoverflow.com Feb 28 '11 at 20:04

This question came from our site for professional and enthusiast programmers.

7 Answers

I think the interviewer is looking at how you approach unit testing and where you think the limits are within that.

I think there are a variety of "correct" answers.

As to the question of where would you stop I think "a" correct answer would be something like "When I'm satisified that the function performs it's job under normal opperating circumstances and where it fails that the failure is captured and not allowed to break the code" or something to that effect.

share|improve this answer
3  
I would say that your answer is right and that it's a sufficiently vague answer a very vague question. –  Steve Evers Feb 28 '11 at 21:13
add comment

He is trying to see how you think and how you work. There is no good-bad, right-wrong answer here (except, off course, from the very obvious ones).

share|improve this answer
add comment

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.

share|improve this answer
3  
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
2  
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
add comment

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.

share|improve this answer
1  
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
add comment

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?)
share|improve this answer
add comment

My answer would be: I would write as many tests as it took for me to feel confident of the code's stability under the conditions identified in the specifications.

share|improve this answer
add comment

Too much detail on their side i suppose. I would answer that there is no functionality without testing. Thus, to write the function, you test first (Red/Green/Refactor).

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.