-
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
Refactoring and testing DeltaBot #42
Comments
Another thing that could really help contributions (and keeping functions "pure") would be to split up |
|
Hey, I've been busy (and then on vacation) for the past two months. I don't know if I'll be able to continue contributing to this project, as I'll be pretty busy for the forsee-able future. Here are my thoughts on all of this:
If people want to enforce PEP8 that's fine, but I considered it a low priority. A lot of the "over 80s" come from the other PEP8 infraction of using 4 space tabs, which makes keeping lines to 80 chars rather difficult. I also think PEP8 line limits and 2-space tabs result in poor readbility, but that's just my opinion. If you want to sort this out go ahead, but I think it's less important than the points below.
I agree, but the more I dug into deltabot, the harder that task became. Messages in the inbox can cause the bot to recheck old comments, so the line between an "inbox scanner" module and a "comment scanner" module is a little blurry. It definitely can and should be done, but it'll require careful thought and management. Any refactors will have a high chance of introducing new bugs, which is why I made testing the first priority. This thing gets pushed out to a pretty big subreddit, if some bug causes it to start handing out deltas left and right, it'd be difficult to correct it. So testing before deployment will be very important.
I think you might be right here, but I can't remember for sure. The mock-Reddit I was using for testing throws away the login info, so I don't think a separate "Test account" is really needed. A note on testing in general: When making reddit bots, pretty much everything you do is a side effect. At the moment, the best testing solution I could come up with was to mock everything. However, there are no good reddit mocks available, so I adapted one from someone else's bot. It's not a perfect way to test, but it beats setting up a private reddit instance or testing on live reddit. |
Hey, quick question regarding the "impure" functions: how is |
It was impure before I changed it to have the lookup of parent occur in scan_comment_wrapper( ). Some of the list is out of date.— On Sun, Mar 30, 2014 at 2:06 AM, Preston Carpenter
|
Per #58, this issue should be closed. If you are still using this issue, please finish or migrate any remaining work and then close. |
Hey! So I've been talking with PixelOrange about making this project easier to test. Given that many people are coming and going on this project, I think testing would be a great way to make sure new contributors don't accidentally step on old code or break something that was written a long time ago.
If you are currently working on adding a feature, that's fine, but try to follow these principles as much as possible:
-Write pure functions: If given the same input two times, the function should give the same output both times.
-If you have to make calls to praw, do them higher up and then pass the results into your new function.
-Don't log inside of your functions: rather, return a variable containing what you would have logged, along with the result of the function. (this is less important)
Here's a list of the pure and impure functions with their side effects.
Pure:
get_first_int
flair_sorter
skippable_line
str_contains_token
markdown_to_scoreboard
scoreboard_to_markdown
string_matches_message
is_comment_too_short
scan_mod_mail
Impure:
write_saved_id(uses logging and file I/O)
read_saved_id(uses logging and file I/O)
init(logging, praw calls)
send_first_time_message(praw calls)
get_message(random numbers)
award_points(logging, calls other impure functions)
get_this_months_scoreboard(praw calls)
update_monthly_scoreboard(logging, praw calls)
adjust_point_flair(praw calls)
already_replied(praw calls)
is_parent_commenter_author(praw calls)
points_already_awarded_to_ancestor(praw calls)
scan_comment(logging, praw calls)
scan_comments(logging, praw calls, calls to impure functions)
command_add(praw calls)
is_moderator(praw calls)
scan_message(logging, praw calls, system calls)
rescan_comment(praw calls)
rescan_comments(praw calls, calls to impure functions)
scan_comment_reply(logging, praw calls, calls to impure functions)
scan_inbox(logging, praw calls, calls to impure functions)
update_scoreboard(logging, praw calls, time sensitive)
get_top_ten_scores(praw calls)
get_top_ten_scores_this_month(praw calls, time sensitive)
update_wiki_tracker(logging, praw calls)
update_wiki_tracker(logging, praw calls, calls to impure functions)
go(logging, praw calls, calls to impure functions)
We don't need to purify every function, but if we can move all the side effects up to go(), init() or other high-up functions, it will make everything else MUCH easier to test.
Ideally, I'd like to pass scan_comments() a list of comments and other data, and get back a list of output actions that need to be performed. In the meantime, if someone could get a unit testing library set up to test the pure functions, that'd be awesome.
The text was updated successfully, but these errors were encountered: