Skip to content
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

[Identity] Refactoring the HTTP request mocking to be easier to understand in context #19824

Merged
merged 4 commits into from
Jan 14, 2022

Conversation

sadasant
Copy link
Contributor

@sadasant sadasant commented Jan 13, 2022

Checklists

  • Added impacted package name to the issue description

Packages impacted by this PR:

Identity.

Issues associated with this PR:

Fixes #19420

Describe the problem that is addressed by this PR:

Identity tests rely on some functions that mock the internals of our HTTP clients to extract the outgoing requests and responses, so that we can mock the responses, and later match the network behavior based to our expectations. These functions are rather complex at the moment.

What are the possible designs available to address the problem

Refactoring in my mind means minimal efforts that slowly reduce technical debt over time.

With that in mind, I think the most immediate way to improve this design is to move it from a closure to a class.

Closures are not that common in our SDK, in comparison to classes, which are everywhere.

Classes also help identify the context from which the variable come better than closures (the this.name is easier to contextualize than just name).

My intuition tells me there are many more improvements I could make, but I don’t know how much time it will take me, so I am budgeting this PR to be the fastest approach that could yield a meaningful improvement rather than a thorough overwrite.

@ghost ghost added the Azure.Identity label Jan 13, 2022
@sadasant sadasant changed the title [Identity] Refactoring the HTTP request mock to be easier to understand [Identity] Refactoring the HTTP request mocking to be easier to understand in context Jan 13, 2022
throw new Error("No responses to send");
}
const { response, error } = responses.shift()!;
const { response, error } = this.responses.shift()!;
Copy link
Member

@KarishmaGhiya KarishmaGhiya Jan 14, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if this happens to be null, will the program exit abruptly?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes! I will improve this to throw if there are no responses left. Thank you!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, in this case it wouldn’t be possible since we check if there are no responses left above, but your comment helped me see that a similar check was missing on the Node side: a61450e

@sadasant sadasant enabled auto-merge (squash) January 14, 2022 02:47
@sadasant sadasant merged commit dd5b1f6 into Azure:main Jan 14, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Identity] Simplify the HTTP request mock for Node and the Browser
2 participants