Hi Kevin,

Thanks for your question.  I'm not sure we want to change the method
signature that won't be used by the running Golang, but haven't said that
I'd like to see an example of what you are describing.  (Maybe a github
gist?)

-Dew

On Tue, Nov 7, 2017 at 2: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
>

Reply via email to