I am trying test driven development for the first time (test first development, actually). I wrote down my specifications, then alternated writing tests, then code, writing the code to pass the latest test and not break prior tests. My code is doing input validation on a user-supplied file path:

  • Does the path exist and is it a file?
  • Is the file in a specific format?
  • Does the file contain a specific field?
  • Does the file have a feature where the field is set to a given value?

This led me to write functions that return True/False for each condition, and tests for inputs leading to True and False outputs. However, there is some duplication between the functions (loading the file, etc.) and I could write a more streamlined function that combines all the checking. This is important in my case because the files can be large.

Where I'm having issues:

  • Do I also refactor the tests?
  • If I have a single larger function that outputs True/False based on the sub-checks, how can I still test for the individual specific conditions?
  • Should I instead raise Exceptions, and check that the correct exceptions are raised?
  • 3
    Hint: There isn't a one-to-one correspondence between tests and methods under test. You can write several tests that all target the same method. Commented Aug 11, 2016 at 16:11
  • 1
    Did you also define your interface, so what the user of the class is using? I mean: Does the consumer of the class also call all those little methods or do they have a single interface like: downloadFile(path)? Commented Aug 11, 2016 at 16:20
  • 1
    @LucFranken and RobertHarvey: Thanks for that. That seems to be the missing piece. I need to write the tests for a larger function check_file_validity, and those tests need to be specific enough to cover all the individual conditions in my smaller tests, without one hiding another.
    – Benjamin
    Commented Aug 12, 2016 at 16:08

1 Answer 1


As you build up your body of tests, along with the software to do the functions, you will absolutely have to refactor both the tests and the software being developed.

You have outlined a number of useful paths to follow for aggregating functionality, but we can't really determine which paths to follow. If you create the tests with a clear understanding of the context and direction, the path will often appear before you as you proceed. Part of what you are doing in your early tests is exploring the solution space; when you find the locations in that space that appeal to you, you will tend to converge there, throwing away or minimizing tests in other areas.

As for the question about True/False status, you might consider the command-query dichotomy. If the command is to parse a file, then you can still query the object to determine the answers to the individual questions. Exceptions should be reserved for exceptional situations, and for situations where you don't want to have data tramp through your system to where an appropriate handler can be found.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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