Creating a real file in a unit test?

Question

I'm responsible strictly for documenting and unit-testing a Golang project. In the part of the SUT I'm currently on, a real file, identified by a file path, is being checked for its "Last modified by" time.

Its code is thus:

// AssetTimePath returns a timestamped path
//
// Parameters:
//
// - `s` :  the URL of the file
//
// Returns:
//
// - the timestamped path
// - any errors
func (view *View) AssetTimePath(s string) (string, *errors.ErrorSt) {
    if strings.HasPrefix(s, "//") {
        return s, nil
    }

    s = strings.TrimLeft(s, "/")
    abs, err := filepath.Abs(s)

    if err != nil {
        return "", errors.File().AddDetails(err.Error())
    }

    time, err2 := utilities.FileTime(abs)
    if err2 != nil {
        return "", err2
    }

    return view.PrependBaseURI(s + "?" + time), nil
}

The problem

To happy-path test this function, I would need to create a real file, maybe somehow track its absolute pathname, and delete the file afterwards. This seems inconsistent with unit-testing, as it is concerned with isolating all other factors to test individual units of work (such as the fact that there's even a string containing, but not ending with, ? iff the file exists).

Is it ever acceptable, in a unit-test, to create a real file for testing? If not, is this even fully testable?

UPDATE : I overlooked the fact that I could just pass in the name of the very file the tests, or even this part of the SUT, is written in!

The spirit of this question still remains...

Answer 1

"This seems inconsistent with unit-testing, as it is concerned with isolating all other factors to test individual units of work"

Technically, it is impractical to isolate everything. Most unit tests, e.g., depends on the math libraries of the programming language. Would you mock it?

Unit test isolation aims isolating the unit from the unit with higher risk of interference in the test result. A frontend app can be functionally OK even if some service is broken, that's why we isolate it in unit testing.

Would the timestamp function be of any usage if the OS file system is broken? Maybe not... maybe yes...

Now, speaking of performance, hitting network and file systems can be problematic. That's when you can mocking comes into place.

https://medium.com/agrea-technogies/mocking-dependencies-in-go-bb9739fef008

You can create a interface with a mocked function which returns a hard-coded value in testing. In production, it will delegate to the utilities.FileTime

Is it ever acceptable, in a unit-test, to create a real file for testing?

Everything in software development is a trade-off. If you confident in the file libraries and performance is OK by using the real thing, no problem.