You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is not an issue but a question to all gin.io users / developers.
I am currently trying to figure out how to report busted / API test coverage.
Due to the integrative / indirect nature of the tests run with hit(), there is no direct code coverage path that busted -c could use to connect the test suite driven API calls with the underlying controller implementation.
Does anybody of you have a good idea on how to achieve a code coverage report on indirect / integration tests for gin.io?
I would like to refrain from the naïve approach adding direct calls to the controller's handler functions.
Rather, I am thinking about a way
either for hit() to automatically add a call to the appropriate handler (as configured in routes)
or to read out the configured routes and track the calls to each handler using spies or the like
Anybody with any experience or code for this approach?
The text was updated successfully, but these errors were encountered:
I think that the best testing approach for testing GIN applications is integration testing. This is to ensure that everything, from the nginx.conf file to the routes, is properly set, and this is what the usage of the helper hit() allows you to achieve.
The other option, as you state, is to directly hit the routes stack without even starting nginx (just as Rails does for instance in controller tests).
The latter option would allow you to easily set up coverage; the first one does not. However, for the reasons here above I'd keep the integration approach. Therefore, I'd rule out having hit() to call the appropriate handler.
How to set up spies in a clean way for coverage, though, is another question.
Yes, I would stick with the integration part, too -- no question. Just trying to find a good way to turn the integration tests into integration + unit tests (with coverage) automatically.
The other option I will need (in the very near future) would be a single nginx instance for a complete test group / suite, because starting/stopping nginx for each single test takes quite a lot of time if you have lots of tests (which I have).
This is not an issue but a question to all gin.io users / developers.
I am currently trying to figure out how to report busted / API test coverage.
Due to the integrative / indirect nature of the tests run with hit(), there is no direct code coverage path that
busted -c
could use to connect the test suite driven API calls with the underlying controller implementation.Does anybody of you have a good idea on how to achieve a code coverage report on indirect / integration tests for gin.io?
I would like to refrain from the naïve approach adding direct calls to the controller's handler functions.
Rather, I am thinking about a way
hit()
to automatically add a call to the appropriate handler (as configured inroutes
)routes
and track the calls to each handler using spies or the likeAnybody with any experience or code for this approach?
The text was updated successfully, but these errors were encountered: