I am relatively new to automated testing and although I understand the basics to be able to "do it" I don't know much about what are best practices and why.

Specifically I am trying to figure out the best way to write unit tests for a function that reads a table from a pdf file and returns a data structure (In this case I am using Python and the function returns a pandas DataFrame).

The question I am not sure is that would be a good way to test it ... some of the ideas I can come up with are:

  1. Have a "real life" pdf file exactly lie the ones I the function will be reading in real life. I see a couple of cons to this approach:

    • The file will be a mix of use cases and so the logic and testing in the unit test will be very complex and mixing basic cases with boundary conditions, etc.

    • It will be impossible to find a "real world" file that has all the cases that need to be tested so one might end up with more and more files

  2. Have a "fake" pdf file that is a stylised version built specifically to test what needs to be tested.

  3. Some other approach that I can't think of and that does not require storing external files?

What would be good practice for that type of problem? Is creating external files generally accepted and a good thing for unit tests? For unit tests I would be inclined to have "fake" files, is that reasonably good?

Thanks in advance for all yout thoughts!!!

  • You have a mix - test the main happy and sad paths at an integration level with actual files, and have lower-level tests independent of the file system to cover more of the breadth of the functionality.
    – jonrsharpe
    Commented Nov 11, 2021 at 12:15

1 Answer 1

a function that reads a table from a pdf file and returns a data structure

From your description you can see this function breaks the Single Responsibility Principle:

1 - It does the reading of the file;

2 - It creates a data structure with the relevant information;

Since we have two responsibilities, you can refactor to two functions.

The first function will read a file into some sort of File object that you control; this you can check using mocking libraries, e.g. (in Java) Google's JIMFS.

The second one will receive a File object and return the data structure that you mentioned. In this case, you can create File objects in the test function itself, dealing with the multiple use cases with very low runtime cost.

  • That's very helpul. If I have a function that then calls each of those in turn, would I need to have unit tests for that third function too? or would it be ok to just test that the third function calls each of the two and they are tested? Commented Nov 11, 2021 at 19:19
  • Unit tests are made for public APIs. A set of public + many private methods are usually a result of one big public method developed driven by unit tests followed by many extract method refactorings. These private methods are not part of any public API. If you call public methods, these would have to be developed driven by unit tests in the first place, because they are not bound to this callee. Commented Nov 16, 2021 at 11:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.