Incorrect file access in unit tests?

Question

When writing unit tests related to XML (for example, test a class that reads / generates XML), I used XML-String / my input XML String in separate files next to my unit test to write approved results. Say I have a class called "MyTransformer" that converts one XML format to another. Then I would create three files in one package:

• MyTransformerTest.java
• MyTransformerTestSampleInput.xml
• MyTransformerTestExpectedOutput.xml

Then my statement may look like this (simplified pseudocode for reasons of simplicity):

Reader transformed = MyTransformer.transform(getResourceAsStream("MyTransformerTestSampleInput.xml"))); Reader expected = getResourceAsStream("MyTransformerTestExpectedOutput.xml"); assertXMLEqual(expected, transformed); 

However, a colleague told me that access to the file that I have in this unit test is not acceptable. He suggested creating a literal string constant (private static final String) containing my XML file content, possibly in a separate groovy class due to the advantage of multi-line strings, and not for writing an XML file to files.

I don't like the idea of ​​string string constants, because even if I have multi-line strings in groovy, I still lose the syntax highlighting and all the other useful features of my XML editor that tell me right away if my XML is syntax errors, etc. .

What do you think? Is file access really bad? If yes: why? If not, then why is this normal?

Answer 1

Two problems with files in unit tests:

• they slow down the testing cycle. You can have thousands of unit tests, which, preferably, run at each build, so they should be as fast as possible. If you can speed them up (for example, by getting rid of I / O), you will want to do this. Of course, this is not always possible, so you usually select “slow” tests through NUnit [Category] or something like that - and then run these special tests less often - say, only on nightly buildings.
• they introduce additional dependencies . If a file is required for verification, it will fail not only if the logic underlying the test is incorrect, but also if there is no file, or the tested runner does not have read permissions, etc. Which makes debugging and fixing not so enjoyable!

However, I will not be too strict not to use files in tests. If possible, try to avoid them, but do not be angry. Make sure you consider maintainability and speed — the cleaner the test, the easier it will be to fix and understand it later.

Answer 2

If your device tests access files to submit fake test data to System Under Test, you can run tests, which is not a problem. It actually helps you to have a wider range of test data to implement in your system under test.

However, if your system test checks access to the file system when executed from a test, this is not a Unit Test. This is an integration test. This is because you get access to cross-cutting tasks, such as the file system, and they cannot be classified as Unit Tests.

You really would isolate / fake file access and test your code behavior (if any) using Unit Tests. They are faster and easier to work. This gives you accurate feedback if it is spelled correctly.

Answer 3

In these cases, I have a unit test that uses the internal representation of the file, which in this case is a string literal.

I will also have an integration test to verify that the code works correctly when writing to a file.

So, it all depends on the definition of the Unit / Integration test. Both are valid tests, it just depends on which test you are writing at that time.