The rules are:
- It must be a unit test (so don't touch the file system).
- The public signature for
CodeUnderTest
must not be changed.can be extended not reduced - You're allowed to use DI/your favorite mocking framework.
- You can only add code where you see /**/.
[Test]
public void Test()
{
/**/
var text = CodeUnderTest.GetUpperText("foo.txt" /**/);
Assert.That(text, Is.EqualTo("BAR"));
/**/
}
public class CodeUnderTest
{
/**/
public static string GetUpperText(string path /**/)
{
var text = File.ReadAllText(path);
return text.ToUpperInvariant();
}
/**/
}
Please comment below or tweet me @jcansdale.
Add a IFileDataProvider but at this point your test has essentially become useless as it just tests string.ToUpperInvariant() you will later need a test on FileDapaProvider that it actually reads the data. That said hitting a small file in a unit test is not the end of the world. People like to get caught up in whether something is an integration test, a unit test, an acceptance test, etc; What I am interested in is "is it fast or slow"
I should add that "static mocking the file method" essentially does the same.
TDD is not the be all end all of everything. I would suggest spending time on something more productive like learning queue theory.