I have a unit I'm testing which generates a file name and saves something there. I will need to pull the file out of that location to test it was stored right. I know how the file name is generated, however, hardcoding the logic for file name generation throughout my tests feels like a 'Magic Number' to me. Is there a better approch?
I thought of pulling the logic that generates the path name out into it's own helper method in the unit I'm testing, and testing that method once, then using that method when I need a path name. Then I only 'hardcode' the path generation logic in one test where it seems reasonable. However, if I did pull that method out it would usually be a private method, which brings up the whole question as to how to test it, rather it's fair to make it public just for testing, and is it a code-smell to be testing helper functions at all.
What is the most elegant way of testing something like this? just hardcode it?
1 Answer 1
option 1.: mock the name generation code and test it separately.
pro: you control where and what file is used, no random dangling files to clean up.
option 2.: mock writing to the file.
pro: no need to go to the file system at all an instead save to a byte buffer.