-
Notifications
You must be signed in to change notification settings - Fork 104
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
Java Testing example using Spock #287
Java Testing example using Spock #287
Conversation
@@ -0,0 +1,240 @@ | |||
# Java Test Samples Starter Project |
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.
Any reason for adding Spock specs to a new sample instead of the existing one apigw-lambda-list-s3-buckets
? Ideally, JUnit and Spock tests can live in the same app.
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 had the same mixed feelings on this - I figured if I was looking / searching for examples with Spock this would be the least path of resistance for me as I wouldn't typically expect a mix of tests that tested the same outcomes.
My second consideration was for Java developers that may not have familiarity with Spock and adding a groovy package alongside the JUnit examples may add confusion in terms of dependencies etc. Happy to merge to the existing codebase if it makes a more coherent solution.
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.
@mridehalgh Thank you for the explanation. I agree with the sentiment. However, I strongly believe maintaining in the existing code will be better because of following reasons:
- The sample apps are created based on a serverless use case instead of a focus on a specific test framework
- The application code is repeated. Therefore, not DRY.
- Maven allows
profiles
which I believe can be used to have selective dependency management when it comes to JUnit and Spock. Keep JUnit profile asdefault
and activate a new profile to show case Spock test on-demand. - Lastly, the best place to elaborate your thinking process will be in the README file of the existing app. Create new section on Spock and elaborate all of the above including how Spock tests work.
I believe you can achieve more by doing less. Let me know what you think.
[[top]](#api-gateway-to-lambda-to-list-s3-buckets) | ||
|
||
## Run a unit test using a mock framework | ||
You can use Spock to mock the service calls that are being done in the Lambda 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.
Spock is more than a mocking framework. It will be ideal if you can showcase BDD using Spock.
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.
Agree around it being more than a mocking framework. I will get that title changed to better reflect Spock.
I would argue that although BDD is the spirit of Spock and certainly has a Gherkin-style syntax to define steps examples of BDD is a wider and broader topic than a testing example and would probably warrant a larger project.
Example of unit, and integration tests using Spock for a pattern using API Gateway, AWS Lambda and Amazon S3.