Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question: API Test Coverage (gin.io + busted + luacov) #30

Closed
istr opened this issue Sep 11, 2015 · 3 comments
Closed

Question: API Test Coverage (gin.io + busted + luacov) #30

istr opened this issue Sep 11, 2015 · 3 comments
Labels

Comments

@istr
Copy link
Contributor

istr commented Sep 11, 2015

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?

@ostinelli
Copy link
Owner

Interesting question.

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.

@istr
Copy link
Contributor Author

istr commented Sep 14, 2015

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

@istr
Copy link
Contributor Author

istr commented Jan 14, 2022

Outdated.

@istr istr closed this as completed Jan 14, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants