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
