We are working on an application that has a lot of dependencies/gems that are not tested.
What would be the best way improve the testing suite for the dependent gems, since we can’t get any metrics, such as code coverage (on the external gem), when the tests reside in the main application.
The problem is that part of the application has been packaged as a gem, without any tests, but this gem is still dependent on the main application (weird, I know). Therefore testing the gem itself is not really an option, and it seems like it would be best if the whole test suite stays inside the main application.
Is there a way to include code coverage for gems, when tests are performed from a Rails app, or we should really be testing the gem inside itself?
@nonsens3 ideally, tests would reside in the gem for a few reasons. First, it allows you the opportunity to write tests first, fully decoupled from the application in which it’s used. Second, it encourages encapsulation and cleaner APIs because you’re forced to test and interact with the gem outside of the context of the existing application. Finally, because the app and the gem are separate entities, it’ll be easier to extract the gem and reuse it while having confidence that it works correctly (you shouldn’t have to copy tests between apps for the same gem).
As for how to achieve this, I’d recommend doing a little bit of digging about how to test Rails Engines (which it sounds like this gem is). With RSpec, the common pattern is to have a spec/dummy directory holding a Rails app that you write tests against. I won’t outline this in this post as there are good resources online outlining this process.
This was my thinking as well. The problem is that, as I mentioned, the gem is dependent on the application… I guess we will first need to refactor all this mess, before moving to the test suite task.