freeformz had a good suggestion to try to make your function take an io.Reader, which is good not just for testing, but for future flexibility... but of course, you still need some place that opens the file... that's inescapable. The way I test those sorts of things is to use a variable to hold the function variable, and swap that out during testing:
https://npf.io/2014/04/mocking-functions-in-go/ The article I wrote suggests a global variable, but that restricts you from doing parallel tests (and global variables are generally bad)... you could also make it a variable on the struct that has the method you're testing, then it's isolated from other tests and values... i.e. type myObjStruct struct { ... OpenFile func(string) (*os.File, error) } then when you construct the type, in production you do myObj.OpenFile = os.Open and in testing you do myObj.OpenFile = testOpen (or whatever) -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
