-
Notifications
You must be signed in to change notification settings - Fork 41
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
base: main
Are you sure you want to change the base?
feat: Add spies #171
Conversation
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? |
Updated documentation as requested @cjoecker |
Just following up to see if this can be merged and released? |
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.
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> { |
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.
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.
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 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.
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 said, I'll take another look as it may make sense from a testing perspective to have these inherited
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.
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; |
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.
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.
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'll remove the restore
check
TopicArn: "arn:aws:sns:us-east-1:111111111111:MyTopic", | ||
Message: "My message", | ||
}), | ||
); |
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.
Please restore the original README formatting and only apply your changes.
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.
Will do
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 |
@chris-armstrong no worries. I'll probably try to make changes myself when working on other things in the future. |
Allow the use of sinon spies for when you want to validate behaviour on real API call implementations.