Copy Page

You are not logged in. Any changes you make will be marked as anonymous. You may want to Log In if you already have an account. You can also Sign Up for a new account.

<p><strong>Unless you are testing a file utility class, if you access files during your test, you exceeding the scope of the <em>unit</em> that you should be testing.</strong></p>

<p>That statement sums up the principle behind this rule. However, there are more pragmatic reasons to consider as well.</p>

<h4>Clarity / Evident Data</h4>

<p>Often the motivation for violating this principle is to read test data. Separating test data from the code of your test class makes that test significantly harder to understand and debug.</p>

<p>In his TDD book, Kent Beck alludes to this practice as <em>Evident Data</em>. Show the reader of your test the intent of the code being tested by using clear and understandable data as parameters to your code and expected results in your assert statements. Once test data moves to a separate file, especially in binary formats, the maintenance cost and usefulness of that test becomes worrisome.</p>

<h4>Speed Of Execution</h4>

<p>Reading files is much slower than executing code. Most </p>

<h4>Ease of Setup and Brittleness Issues</h4>

<p>Unit tests that depend on files being in the right place in order to pass can no longer be executed simply with a test runner and proper classpath. They must be executed in the context of a build which ensures that the files used are in the right place to be read by the test. This raises maintenance concerns, since changes to the test files would cause your unit tests to break in possibly hard-to-understand ways.</p>

<h4>Design Considerations</h4>

<p>Most of the time what you really care about is streams. Your design should be flexible enough to deal with other sources than files. By accounting for this you will also get a more flexible design.</p>

<h4>Recommendations</h4>

<ul>
	<li>Design all classes that have a legitimate need to read files be coupled to the rest of your codebase via interfaces.</li>
	<li>In some cases, consider using URLs instead of File classes. URLs have handlers which can be mocked out quite easily.</li>
	<li>Create a separate, non-Ashcroft integration test suite with tests to cover implementations that read files.</li>
</ul>