title: TDD - How to test .Read() without .Write()?
body: <p>We're trying to use TDD to create our system and we've come to a situation where we can't figure out what the right TDD course of action is.</p>
  
  <p>We've hidden the file IO behind an interface like so:</p>
  
  <pre><code>public interface IFileIo
  {
      byte[] Read(string fileName);
      void Write(string filename, byte[] data);
  }
  </code></pre>
  
  <p>and now we're creating an <code>InMemoryFileIo</code> that we can use in place of the real <code>SystemFileIo</code> class that we'll use for production.</p>
  
  <p>We want to make sure this <code>InMemoryFileIo</code> works correctly and there may be cases where we want to use it in lieu of the actual file system, so it should be "production quality".</p>
  
  <p>The question is, doing everything the "right TDD way", how can we create a test for either <code>.Read()</code> or <code>.Write()</code> where they don't depend on each other?</p>
  
  <p>In order to test that <code>.Read()</code> worked correctly, we would have needed to successfully made a call to <code>.Write()</code> first, and similarly, to test that <code>.Write()</code> works correctly we would then need to call <code>.Read()</code> afterwards. By doing this, we've actually created the same test twice (arrange, then a write, then a read, then asserts).</p>
  
  <p>Lets say we have two tests, one that tests <code>.Read()</code> and one that tests <code>.Write()</code>. If either of those functions doesn't work, then both tests fail. This violates the principle that "A test should only have one reason to fail".</p>
  
  <p>The example here is for file IO, but this same question has come up for us when working with a database (test <code>put</code> without <code>get</code>).</p>