Given the method signature you provided, you can 'simply' unit test the ReadFile method by invoking it with a lot of different input and verify that the return value is correct.
However, this can lead to Obscure Tests because very important test input is hidden away in files instead of being visible when you review each test.
This is where TDD shows its force because it should prompt us to consider a better API.
You could, for example, change the method to this:
public Dictionary<string, string> ReadFile(TextReader reader, string delimeter)
It's still pretty easy to get a TextReader from a file, but now you can alternatively use a StringReader to supply unit test input.
This change will not only make it easier to unit test the ReadFile method, but also make the method more generally usable because it no longer has a tight coupling to the file system.