Skip to content

feat: Add spies #171

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

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open

Conversation

chris-armstrong
Copy link

Allow the use of sinon spies for when you want to validate behaviour on real API call implementations.

@chris-armstrong chris-armstrong changed the title Add spies feat: Add spies Jul 11, 2023
@chris-armstrong chris-armstrong marked this pull request as ready for review July 11, 2023 05:20
@cjoecker
Copy link

cjoecker commented Nov 7, 2023

Thanks for the PR! I was looking for a way to use the spies. @chris-armstrong wouldn't it make sense to add also something about it to the docs?

@chris-armstrong
Copy link
Author

Updated documentation as requested @cjoecker

@chris-armstrong
Copy link
Author

Just following up to see if this can be merged and released?

Copy link
Owner

@m-radzikowski m-radzikowski left a comment

Choose a reason for hiding this comment

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

Sorry for not reviewing it earlier.

Please see my comments.

*
* To define resulting variable type easily, use {@link AwsClientSpy}.
*/
export class AwsSpy<TInput extends object, TOutput extends MetadataBearer, TConfiguration> {
Copy link
Owner

Choose a reason for hiding this comment

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

Because Sinon Stub extends the Spy, we could do the same here - AwsStub extend AwsSpy. The call(), calls(), and commandCalls() could be defined only in AwsSpy.

Copy link
Author

Choose a reason for hiding this comment

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

This makes sense in theory, but in practice, the type shenanigans needed to type the send value and the reset call so they return different types makes this extremely difficult (and probably very confusing to downstream users).

I did experiment with this, but I think it's better to have separate definitions and avoid the complexity of inheritance.

Copy link
Author

Choose a reason for hiding this comment

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

That said, I'll take another look as it may make sense from a testing perspective to have these inherited

Copy link
Owner

Choose a reason for hiding this comment

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

Okay, thanks, let me know if you don't find a sensible way to implement this, I will take a look then or we will leave it as it is 👍


export const isSinonSpy = (obj: unknown): obj is SinonSpy =>
((obj as MaybeSinonProxy).isSinonProxy || false)
&& (obj as SinonSpy).restore !== undefined;
Copy link
Owner

Choose a reason for hiding this comment

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

Those methods do not distinct between Sinon Stub and Spy. But we don't really care about the distinction, only whether the object is any Sinon Proxy - Stub or Spy. We can get rid of the restore existence check and just make it a single isSinonProxy() function.

Copy link
Author

Choose a reason for hiding this comment

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

I'll remove the restore check

TopicArn: "arn:aws:sns:us-east-1:111111111111:MyTopic",
Message: "My message",
}),
);
Copy link
Owner

Choose a reason for hiding this comment

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

Please restore the original README formatting and only apply your changes.

Copy link
Author

Choose a reason for hiding this comment

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

Will do

@chris-armstrong
Copy link
Author

I'm really sorry, I've not been able to get onto this - trying to reuse the type definitions was too difficult, and I've not had time to work on it sorry

@m-radzikowski
Copy link
Owner

@chris-armstrong no worries. I'll probably try to make changes myself when working on other things in the future.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants