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 all 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.
👍
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.
👍
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 shared example relies on the spec including it (
include_examples 'github_token_initialization'
) defining arun_action_without
method and adefault_params
. The only way a consumer would find out about this would be by running the tests.E.g. if we rename
run_action_without
to something else insetfrozentag_action_spec
, we get:In Swift, we'd do something like constraining this to tests that conform to a certain
protocol
. There's no such thing in vanilla Ruby that I'm aware of.There might be a way to update
run_described_fastlane_action
to add it the capability to do_with
and_without
, but that wouldn't solve the implicit dependency ondefault_params
🤔At this point, the only thing I can think of is to document the requirement as a comment at the start of the file. What do you think?
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.
shared examples can also contain metadata, that you can then pass as additional params when you call
include_examples
. I think that would be a better way to passdefault_params
.As for
_with
and_without
variants, I wonder if it's worth relying on those existing in the implementation ofshared_examples
vs just directly usingdefault_params.except(…)
anddefault_params.merge(…)
so that we don't rely on those_with[out]
methods existingThere 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.
Indeed, when I try to use the shared examples passing the
default_params
as metadata, the RSpec blocked me from doing so. The error that I receive is: As we have thedefault_params
as a:let
variable it is not available on an example group (e.g. adescribe
orcontext
block). It is only available within individual examples (e.g.it
blocks).In that case, I don't know what is the best alternative here, if is to keep the shared examples relying on the existence of a variable named
default_params
and document this as @mokagio suggested. Or to redundant use another:let
variable to pass that metadata as in this example 🤔Yeah, I have that "dilemma" when I was implementing this, I was first defaulting to those approaches of having the
merge
andexcept
instead of relying on the_with
and_without
functions to exist. However, as I didn't find a good way to pass the params to inside the shared models, I end up following the same pattern that I was in the examples and relying on the existence of those methods as I do not want to duplicate them inside the shared examples.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.
Also, there is this third option to do it, which is cleaner than the other one, but I find it a little bit confusing the way that it used the
send
with the variable name (from a perspective of a person who does not has so much knowledge of ruby 😅)But again, although I feel that this third option is cleaner, I have no strong option about which one is the right one that we should use 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.
Tbh I'm not a fan of using
send(…)
, both because it's lesser known, but also because it feels like a trick more than a proper official way to do this (the times I've used it was mostly to workaround some limitations rather than to implement something cleanly).What about using metadata, but workaround the limitation that
let
is only visible in example and not groups… by declaringdefault_params
as a function (def
) rather than alet
? I know that's what you had in an earlier iteration of the PR before I gave you some feedback thatlet
is usually better suited for constant values, and that's still true, but if that is a blocker for us using it ininclude_examples
' metadata, then I think it's ok to go back todef
for that case then. At least I'd personally prefer this over usingsend
🙃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 find the use of
send
kinda odd too 🙃.However, even if I change
default_params
to adef
function, I still receive the same error from the RSpec as using it as alet
variable.The only way that seems to do the job (although is not a DRY solution), without using the
send
, Is to repeat the declaration of the parameters at the call of theshared_examples
like this:Let me know what you think about this suggestion 😄