Re: Traffic Ops Golang Unit Tests Pattern

[Dewayne Richardson]

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  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
>

Re: Traffic Ops Golang Unit Tests Pattern

[Oren Shemesh]

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  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 | or...@qwilt.com

Traffic Ops Golang Unit Tests Pattern

[Kevin Mackenzie]

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