Modifying the tests and refactoring duplicate code in test driven development

Question

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?

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.