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.
Looks like a method containing both file system operations and business logic. I'd split them.
One method (impure) for getting the file content, or null if no file.
One method (pure) containing the rules for how to format the result.
These methods would be standalone and you would only have to change one of them if the data layer or business rules changed. Integration tests for the first. Unit tests for the second (which often contains the edge cases and complex logic).
I remember one article that described an idea as "dependency elimination", which I guess this relates to.
http://qualityisspeed.blogspot.no/2014/09/beyond-solid-dependency-elimination.html
(And since this is the internet, obligatory troll content: "Mocking considered harmful" ;)