AliSoftware
Add path component matching to request testing
Overcoat implements service endpoint testing in a neat fashion:
You don't need to specify the full path, and you can use * and ** to match any text or # to match only digits.
If you use * and #, they are strict path matchings, so the number of path components must be equal. The ** just matches any text and has no path components number limitation.
| Match String | Path | Result |
|---|---|---|
| statuses/* | statuses/user_timeline | Matched |
| statuses/# | statuses/user_timeline | Missed (wrong type, the path component after statuses should be dights only) |
| statuses/* | statuses/retweets/12345 | Missed (wrong number of path components, there should be only one path component after statuses) |
| statuses /* /* | statuses/retweets/12345 | Matched |
| statuses/** | statuses/retweets/12345 | Matched |
| statuses/** | statuses/retweets/12345/extra | Matched (the number of path components doesn't matter) |
| statuses/retweets/* | statuses/retweets/12345 | Matched |
| statuses/retweets/# | statuses/retweets/12345 | Matched |
It'd be really neat if OHHTTPStubs had a method that implemented similar logic, rather than always having to manually work out this logic on every single test.
Very nice idea! :+1:
Do you have any idea about a simple implementation? The one from Overcoat is quite tightly coupled with Mantle.
The only thing I'm wondering if, is OHHTTPStubs the right place to implement that? I mean, it could work both for OHHTTPStubs and for any other various uses (like even in your app you could need such logic), and I prefer to have multiple small libraries that are focused on a feature than one big lib that keeps growing and become a huge machinery in the end.
For example, I already hesitated adding the matchers I wrote as part of the Swift subspec (but they are simple enough, so that's ok I guess), but someone already suggested me to make it possible for OHHTTPStubs to record network traffic, and I feel that it's the responsibility for a dedicated pod instead of clobbering OHHTTPStubs
Anyway, that's still a nice idea and would be great to have a dedicated library for that. Won't have time for that anytime soon, but don't hesitate to start one on your own on which I'd be glad to contribute when I'm a little less busy ;)
I'd absolutely agree having a separate library. When I get a chance, I'll do a little digging around to see if there is already a library for this, or at least something to start from.
Hey @janglesdev any news on that front?
Stubbled upon https://github.com/kylef/URITemplate.swift the other day which might be an interesting starting point to implement this?
That's an interesting approach. I've actually been using an extremely simple URL matcher I wrote quickly based off the idea. It just has one method, takes an NSUrl alongside the test string, and returns a boolean of whether it checks out. I'm far from being a networking expert, but I really like his approach. I'll give it a go one of these days, and check back
Note: upcoming version 6.0.0 (see #242) will add a pathMatches(…) matcher function helper. It's not as powerful as a whole component matching mechanism like URITemplate but it could help in a lot of situations.
Like pathMatches("^statuses/") and pathMatches("^statuses/retweets/[0-9]+/extra$") would both match the path statuses/retweets/12345/extra.