-
Notifications
You must be signed in to change notification settings - Fork 18
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
Write test suite #11
Comments
Hi Jordan, thanks for opening this issue! We would really welcome a PR for a test suite 🙌 Hopefully the refactor in #10 (now merged) will help with that as there are now more atomic functions. If you wanted to join, we have a channel in our Discord dedicated to development of this tool https://discord.gg/bellingcat |
Hi @jordan-gillard and @GalenReich My idea would be to engineer it such that the test functions go as far as formulating the URLs of the API calls and then validates that the URLs are properly formed, but validate nothing about what is returned to that call. This way the test suite is not dependent on the EDGAR API to pass. Then I could introduce a test which does try the API, but only raises a warning if it doesn't work. This way if there's an issue with the EDGAR API, we know there's a problem, but it doesn't cause unit testing to outright fail. Let me know your thoughts. It is also fine to design the tests to go as far as hitting the API and retrieving results, we just need to establish some queries that we know will always return a certain result. |
@jordan-gillard Is there anything in process on this? I am not seeing anything in your fork. Which mocking modules do you usually use? I can start something but would want to do something compatible with where you are going. |
I'm going to unassign @jordan-gillard as we haven't heard from him in a little while, and it seems that there is some enthusiasm here! Jordan, if you want to get back involved in an advisory role, just hop back in, we'd be grateful to have you! For @JackCollins91 and @rkiddy, we have used I'm going to assign Jack to this issue as he's posted a bit of starting detail, but I'd encourage you both to collaborate on this. Though if you'd rather work independently, I'd also welcome a PR to add tests to https://ShadowFinder. Let me know if you'd like to collaborate on this or be assigned elsewise. |
Hey @rkiddy, I'm happy to implement this, but wouldn't have time until about September (maybe sooner, but not certain). If you're enthusiastic and have time before then, you're welcome to take over this PR and I'd be happy to chat/code review or advise, etc. If not, no problem - i'll still get to this as soon as I clear my present crunch time. Cheers |
Hi folks! So sorry for being MIA. I've been swamped with some new work responsibilities. @JackCollins91 I initially saw your comment on my phone in the morning, and I thought it came from Discord! I couldn't find it (obviously) and then brushed it off 😅 @rkiddy In my experience, almost all Python testing can be accomplished with Python's built-in unittest library and pytest. As for testing, I think anything is better than nothing. When adding tests to existing code it often begins with integration tests. I definitely agree in @JackCollins91's assessment that we shouldn't use the actual EDGAR API. You could mock out network calls so that they always return a predetermined response. That's usually the way to go. This project uses the For example, if you were testing Line 221 in 97b60fd
Your test file, lets call it @pytest.fixture
def mock_requests_get():
with requests_mock.Mocker() as m:
yield m and then the test would use the fixture and set the response you are testing against: def test_fetch_rss_feed(mock_requests_get):
"""Tests that we do x when the api returns y
yadda yadda yadda
"""
# GIVEN
sample_rss_feed_response = """
<rss>
<channel>
<item>
<title>Something something idk</title>
</item>
</channel>
</rss>
"""
mock_requests_get.get(RSS_FEED_URL, text=sample_rss_feed_response)
# WHEN
fetch_rss_feed(...)
# THEN (though you'd surely want to test more than this)
mock_requests_get.assert_called_once_with(RSS_FEED_URL, headers=headers) Please don't wait on me to add tests! I will work on it today but tbh I don't even remember what I was up to when I last checked out the repo 😆 |
Sorry if this seems lame, but can someone demonstrate how to run something in the local source. I do a lot with python, but mostly with flask apps and I am not familiar with this packaging style. I tried:
But then, how do I execute local code? I made a change to the help string in both edger_tool/rss.py and in edgar_tool/.venv/lib/python3.10/site-packages/edgar_tool/rss.py and running this shows no change:
I am sure I am confused about something here. If I can run something local, I can write tests. |
Hey @rkiddy no worries, mate.
Let me know if that works:) |
The project uses As per the README:
When you do |
I might not be able to help. I think I must use python in a not very pythonic way.
|
@rkiddy You are using virtualenv, but the recommended workflow @GalenReich mentions in #11 (comment) is to use Poetry. I strongly encourage you to use the development workflow recommended in the project's README.md file. You'll have to click the line that says |
I need to preface this issue by saying I love the work you do and that I think this software is very cool.
I notice that this repo doesn't have unit tests. The result of this is that breaking changes and regressions are difficult to catch. I know you guys want to publish EDGAR to pypi, so this is really no bueno. Ideally we'd want a robust test suite that runs in CI for every PR. I think this is especially relevant to PR #10, since it involves major code changes and therefore the strong potential to break existing behavior.
I'm interested in helping Bellingcat, so I'd be happy to work on this or take on an advisory role.
The text was updated successfully, but these errors were encountered: