unit testing - TDD - How to test .Read() without .Write()? -

we're trying use tdd create our system , we've come situation can't figure out right tdd course of action is.

we've hidden file io behind interface so:

public interface ifileio {     byte[] read(string filename);     void write(string filename, byte[] data); } 

and we're creating inmemoryfileio can use in place of real systemfileio class we'll use production.

we want make sure inmemoryfileio works correctly , there may cases want use in lieu of actual file system, should "production quality".

the question is, doing "right tdd way", how can create test either .read() or .write() don't depend on each other?

in order test .read() worked correctly, have needed made call .write() first, , similarly, test .write() works correctly need call .read() afterwards. doing this, we've created same test twice (arrange, write, read, asserts).

lets have 2 tests, 1 tests .read() , 1 tests .write(). if either of functions doesn't work, both tests fail. violates principle "a test should have 1 reason fail".

the example here file io, same question has come when working database (test put without get).

the whole question comes down how define "units". me personally, helps think of "unit" coherent set of behaviour rather single method invocation.

roy osherove defines unit as:

a unit test automated piece of code invokes unit of work in system , checks single assumption behavior of unit of work. unit of work single logical functional use case in system can invoked public interface (in cases). unit of work can span a single method, whole class or multiple classes working together achieve 1 single logical purpose can verified.

so in end, throwing guidelines aside, if not make sense split reading/writing responsibilities test them in combination. in general, when feel there no clean/easy way verify results of test through backdoor (be collaborator can mocked, state verification,...), have no problems exercising other functionality of public api. these tests exercise components through public api's tend less brittle ones use backdoor verification anyway.