The other strategy depends on how to approach the struct initialization. For this snippet, this one makes more sense. That strategy initializes g.GetJSONFx default to getServerJSON before using the struct so you can safely skip the checking entirely inside GetJSON.
You can simulate both request and responses and feed it into your method.
The above strategies are meant for runtime mocking (as in application mocking / changes). Please avoid using it for testing except when your application is using it.
UPDATE: Revert my statement above: you can use the above strategies. Unless the http is outside, only then you can use httptest. My previous proposals would be the good choice.
Sorry, I was working for the past 12 hours striaght.
If you want high efficiencies for GetJSON method, you can do something like init() method. One out of many examples:
type Graph struct {
ClientID string
ClientSecret string
GetJSONFx func(method string, url string) ([]byte, error)
}
func (g *Graph) Init() (err error) {
...
g.GetJSONFx = g.getServerJSON
...
}
func (g *Graph) GetJSON(method string, url string) ([]byte, error) {
return g.getServerJSON(method, url)
}
func main() {
g := &Graph{}
err := g.Init()
if err != nil {
// handle error
return nil
}
// mock it when needed
g.GetJSONFx = func(method string, url string) ([]byte, error) {
... // your custom function
}
for {
d, err := g.GetJSON(...) // calls does not need to check for GetJSONFx during work everytime
}
}