Hi Kevin, I am not familiar with the Golang code at all, but I would like to answer, based on general coding principles. I believe that the pattern you are proposing is not beneficial in the current case. It would have been beneficial if the tested code is required to work in an 'abstract' world, i.e. on top of an interface, implemented by the set of functions that may change between invocations, or between installations, or whatever. This interface (=set of functions) could have been passed as you propose, by a set of parameters.
However, there is no such requirement from the tested code. This means that when changing the code to get all the functions it calls as parameters, you put the burden of supplying these parameters on the code that calls the tested code. Which brings us to my main point: *If the code that calls the tested code supplies the wrong function, it will not be detected by the unit test*. So I would propose staying with the current pattern. Regards, Oren. On Tue, Nov 7, 2017 at 11:34 PM, Kevin Mackenzie <[email protected]> wrote: > Hello, > > I’m a student at RPI working with Eric Friedrich on some Golang routes for > Traffic Ops and I am working on writing unit tests for my code. I am using > the same method as the other tests for mocking SQL queries for the > functions that make them, but for the functions that call the functions > that make the SQL queries, mocking the SQL queries seems kind of > redundant. I noticed this is how “TestGetMonitoringJson” in > monitoring_test.go works. > > One method I found is to mock the functions that make the SQL queries, but > this would require adding function arguments to the functions like > “getMonitoringJson” for the sake of testing. > > For example, “getMonitoringJson” would require additional parameters of > types: > > type MonitoringServercesGetter(db *sqlx.DB, cdn string) []Monitor, > []Cache, []Router, error > type CachegroupsGetter(db *sqlx.DB, cdn string) []Cachegroup, error > type ProfilesGetter(db *sqlx.DB, caches []Cache, routers []Router) > []Profile, error > type DeliverServicesGetter(db *sql.DB, routers []Router) > []DeliverServices, error > type ConfigGetter(db *sqlx.DB) map[string]interface{}, error > > Since “getMonitoringJson” calls functions with above signatures, the > caller of “getMonitoringJson” will need to pass the normal versions of > these functions to it, but in the testing methods, mock versions of these > methods that don’t make SQL queries can be passed. > > Would it be better to integrate this kind of pattern into my code to > simplify the testing methods or to follow the existing pattern and mock all > of the SQL queries required by functions like “getMonitoringServers” and > “getCachegroups” when testing functions like “getMonitoringJson”? > > Thanks, > Kevin Mackenzie > -- *Oren Shemesh* Qwilt | Work: +972-72-2221637| Mobile: +972-50-2281168 | [email protected] <[email protected]>
