Current amount of Unit Test Coverage

[partho-maple]

New Issue Checklist

• [x] I have tried with the latest version of OHHTTPStubs
• [x] I have read the README
• [x] I have read the Using the right Swift Version of OHHTTPStubs for your project section
• [x] I have searched in the existing issues
• [x] I have read the OHHTTPStubs wiki to see if there wasn't a detailed page talking about my issue

Environment

• version of OHHTTPStubs: [6.0.1]
• integration method you are using:
  • [x] Cocoapods
  • [ ] Carthage
  • [ ] submodule
  • [ ] other

Issue Description

I just wanted to know that what's the current amount of Unit Test Coverage of this library ?

[AliSoftware]

Hi

I'd say that OHHTTPStubs is rather well tested, we have quite a lot of unit tests (and also a lot of projects using it in real world, if that counts).

We haven't automated the code coverage reports to show it as a badge in the README for example, but you can open the XcodeProj, check the "Gather Coverage Data" checkbox then run the tests to see the coverage manually. I just did exactly that, and it appears that we're at 75% of coverage overall.

When I look at what's not covered, it's mainly the helper codes to access fixtures from file (e.g. helper methods that wrap calls to [NSBundle bundleForClass:self.class] URLForResource: withExtension:…]; followed by [NSData dataWithContentsOfURL:responseURL]; then responseWithHTTPMessageData:, stuff like that — especially the parts using the Mocktail or HTTPMessage file formats for describing stubs, if you choose to use those subspecs (which are not enabled by default). About all the rest of the code dealing with actually stubbing, the code coverage report seems to confirm that our whole suite of unit tests covers all the main stubbing mechanisms — even if, of course, we're always welcoming PRs and contribution to always add more tests (we never have too much tests) :wink:

[AliSoftware]

FYI

HTH

[Liquidsoul]

I suppose that the question is answered. I'll close this then.