Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
I have some methods im trying to test which use a StreamReader dependency that i mock using Rhino mocks. But it is a large xmlFile. In the spirit of unit testing im trying to keep away from using a test file in my test project.
On the other hand copy-pasting 100 lines of xml into my test class seems sort of ugly. What is the best practice when returning large strings using a stub.
In the spirit of unit testing im trying to keep away from using a test file in my test project.
In the battle between idealism and pragmatism, sometimes a truce is needed.
The main push for not using test files is threefold:
Which conflict against three of the core traits of unit tests: fast, isolated, focused.
But you're right. Having giant blobs of xml in your tests isn't terribly maintainable or pretty. Simply placing a small file into your test project isn't a gross violations of these motivations. In C#, loading a file is dead simple and nearly foolproof. You'll need to work to keep the file isolated to keep it from being an inter-test dependency, and you may need to move it back to code if it slows your tests too much.
I'm not sure what "spirit of unit testing" you are talking about. But if you really need to address that spirit ...
Have basic tests that use small data sets. You can put string constants in your code for this purpose.
Have not-so-basic tests that actually test the things that need to be tested. For these tests, your driver can feel free to call on all the resources you need to get the job done. The file system is such a resource.
The files which contain the test data become configuration items that are controlled in your software configuration management system.
