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