CLIxIndia-Dev / CLIxIndia-Dev/MiTiRobot
Separate out the URL regex in geturl()
- Dominant language
- JavaScript
- Stars
- 0
- Forks
- 1
- PR merge metrics
- No merged PRs in 30d
Description
To make it a little easier to test, I suggest separating out the two regex lines in `geturl`:
```
result = re.search('((http[s]?):\/)?\/?([^:\/\s]+)((\/\w+)*\/)([\w\-\.]+[^#?\s]+)(' + ext + ')', x)
fileurl = result.group(0) # just the url
```
into a separate method, then write a ton of tests against that one. Test for the three URL things that you mentioned in #1 . If any of the inputs are invalid, then this new method should throw an exception that `geturl` should handle / catch appropriately.
* Invalid URLs (404 / 403 / 500 status codes).
* Invalid characters
* Escaping (does Telegram need the URL to be escaped? You can use [urllib.parse.quote](https://docs.python.org/3/library/urllib.parse.html#urllib.parse.quote) for that)
Also, are you limiting it to one URL? Are authors allowed to paste multiple URLs in a message? Right now the code only handles the first one, but if there isn't anything preventing the authors from putting in multiple, then the system won't behave as expected. So I would consider some sort of form validation or change `geturl` to handle multiple results from the regex...and also add a test for that. (0 URLs, 1 URL, 2 URLs).
A comment with examples for what that regex is supposed to filter would also be handy. I can tell it's a URL of sorts, but not the path stuff...and if the URL needs to be escaped before sending it off to Telegram, it would be good to add that to the method.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start at geturl() and trace how its current regex result is used before sending URLs to Telegram. Define the expected behavior for invalid URLs, escaping, and zero, one, or multiple matches, then add focused tests for those cases; done means the extracted URL handling is independently testable and geturl() handles failures appropriately.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- backend
- Issue type
- Refactor
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 30/100