Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Add Unit tests for milestone actions #425
base: trunk
Are you sure you want to change the base?
Add Unit tests for milestone actions #425
Changes from 8 commits
c37f29e
6dfd767
22b9d44
96acb93
f695b04
3472f9e
cdd96c2
3a5a240
5e656dd
b6de4cd
9eb95c2
87ae1d4
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Self-Review: As the
is_string
is deprecated on the ConfigItems, I replace them with the type of variable that we want to receive. This also applies to the other places where I did that change.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is great! It's even a small step towards addressing #278 that we opened a while ago about this 🙂
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be nice and imho makes sense to group those three tests into a parent
describe 'GitHub Token is properly passed to the client'
or something like that.One could even consider finding a way to DRY those 3 tests so that we can easily reuse them in the tests of all the actions that rely on that
github_token
sharedConfigItem
, since those three tests will likely always be the same implementation and logic on all those affected actions.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: why not make this more flexible by allowing it to take a
**options
-style Hash as parameter so you can not only have a nicer call site, but also one that looks like it uses named parameters?Should allow the call site to look like:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I see that you suggested that above, but forget to change it on the newest commit, sorry for that, Already change it 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, here it is! When I saw
default_params
mentioned above in the code, I expected it to be alet(:default_params)
and thus looked for it alongside all the otherlet
declarations at the top, instead of here at the bottom 🙃Any reason why this is a method here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That confused me a bit tbh 🤔.
Because, If I put those in a
let(:default_params)
and then remove params from it, like I'm doing on therun_action_without(key)
, aslet
means that this is a constant by convention and as you stated here, that although is allowed is not right and should be avoided.I thought if I put the parameters again as a
let
and then do those operations, I will be breaking the conventions again. 😅There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
except
is not a mutation method tho (unlike[]
)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice 👍
nit: how about grouping those in
describe 'date computation is correct'
(for the first 3) anddescribe 'raises error when it can't find last milestone'
(or maybecontext 'when last milestone cannot be used'
?) (for the last 2) for example?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah! It will be more organized 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like how you grouped the three cases that all relate to checking the passing of the token to the client in a dedicated
context
group. Any reason why didn't you do the same forclose_milestone_action_spec
for consistency? (See also my other comment with suggestion to DRY that across action specs)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Gosh we really need to refactor the API of this action to use nicer and more comprehensible / consistent
ConfigItem
parameter names for that one… those are quite a mouthful currently 😅One day… in another PR… in the far future… maybe…
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if it wouldn't be the occasion to make this
GithubHelper#create_milestone
method start using named parameters instead of positional ones — that are even harder to identify in test cases like this amongst the otheranything
placeholders. That should then allow us to use.with(hash_including(code_freeze_days: 14))
instead of having to use all thoseanything
placeholders there.But that means a small refactoring of all the call sites though (which might be outside of this PR's scope… but depending on how big a change it would be—not sure there are that many call sites, the
create_new_milestone
action might even be the only one?—, that could still be worth it so we can then have both the call sites and those unit tests be way nicer…I'll let you evaluate how much changes it would warrant to do this, and decide if it's worth it or not.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From what I see, the only places that will be affected are the
GithubSpec
and thecreate_milestone_action/Spec
, I agree that this method should have the named params to "force" it to be better legible and cleaner.However, TBH I do not feel that I should do it on this PR, as it is a bit out of scope (although is a small change). So, I'll open another PR to deal with this, and update these tests here once this new PR is merged 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Update: This is addressed on PR #426 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same suggestions as for the other spec —
run_action_without(key:)
,run_action_with(**additional_keys_and_values)
, andlet(:default_params)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if we can DRY those too using the shared_context, or if this will be too overkill, as we also need to have the
default_params
defined on another place, to share the operations with those two methods 🤔There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should be able to DRY those, or at least group them in a
describe
given how all 3 are relatedThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Self-Review: This for me is an odd behavior of this action If the
:freeze
parameter is false, it does not add the ❄️ symbol to the milestone title, as expected. However, it keeps calling theupdate_milestone
to do an "unnecessary" update at that milestone.Shouldn't in this case, the
update_milestone
not be called, following the same logic in place when the milestone is already frozen?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The call is NOT unnecessary, as it will remove any existing ❄️ emoji from a frozen milestone title if it contains one — i.e. update milestone
20.9 ❄️
to20.9
. This is used when we finalize a release at the end of a sprint, just before closing the milestone (and freezing the next one on the next code freeze).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I didn't notice that behavior. 🤔
I add a test on it in any case, about removing any existing ❄️ emoji from a frozen milestone. 😄