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

Added spock test framework and tests for queue service #4940

Merged
merged 14 commits into from
Aug 15, 2019

Conversation

sima-zhu
Copy link
Contributor

No description provided.

@alzimmermsft
Copy link
Member

Make sure to delete out the old test files and playback records

@sima-zhu
Copy link
Contributor Author

Will have another PR for deletion work.

@sima-zhu sima-zhu requested a review from alzimmermsft August 13, 2019 18:33
then:
QueueTestHelper.assertResponseStatusCode(createQueueResponse1, 201)
def e = thrown(StorageErrorException)
QueueTestHelper.assertExceptionStatusCodeAndMessage(e, 409, "QueueAlreadyExists")
Copy link
Contributor

Choose a reason for hiding this comment

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

This test is mostly exercising the service. Though we do need at least one test per api that returns a failed status code to validate that the Exceptions are successfully translated to a StorageException. This test can be repurposed for that.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Removed. Did not have exception case for create from queue client since all error will be caught from builder.

primaryQueueServiceClient = queueServiceBuilderHelper(interceptorManager).buildClient()
}

def "Get queue client from queue service client"() {
Copy link
Contributor

Choose a reason for hiding this comment

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

I think we can remove this test. I'm not really sure what it's covering.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

After a second thought, I think this one can be used to test if it can return the right class in case it uses a wrong sync and async class. Also have a high code coverage.

then:
queueClient instanceOf QueueClient

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Added one more assertion for better code coverage

Copy link
Member

Choose a reason for hiding this comment

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

I haven't found it yet, so correct me if I'm wrong, but there used to be a similar test as this one but it would make a service call to the queue it got to show that getQueueClient/getQueueAsyncClient doesn't create the queue in the service. If that test doesn't exist could we change this test to do that?

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm ok with having some validation that getQueueClient does not make a service request.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The getClient did nothing but to initialize a new client class.
I don't think the service checking is needed as there is no logic within the service.
I have checked the class type.

QueueTestHelper.assertResponseStatusCode(enqueueMessageResponse, 201)
}

def "Create queues with duplicate name from queue service client"() {
Copy link
Contributor

Choose a reason for hiding this comment

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

I think we can remove this test

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done.

"a_b" | 400 | StorageErrorCode.INVALID_RESOURCE_NAME
"-ab" | 400 | StorageErrorCode.INVALID_RESOURCE_NAME
"a--b" | 400 | StorageErrorCode.INVALID_RESOURCE_NAME
// null | 400 | "InvalidResourceName" TODO: Need to fix the RestProxy before having null parameter
Copy link
Contributor

Choose a reason for hiding this comment

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

We should probably be asserting not null in the builder, no?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Not for API layer. There is checking inside of builder.
I think it makes sense to check null in API as well.
I have updated the API

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I have made changes about checking null for the resource name

@sima-zhu sima-zhu requested a review from rickle-msft August 14, 2019 00:44
Copy link
Member

@alzimmermsft alzimmermsft left a comment

Choose a reason for hiding this comment

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

Let's try to remove as much JUnit as we can and make sure we don't have collisions during concurrent live test runs. Overall it is looking good.

@@ -62,6 +63,7 @@
* @param queueName Name of the queue
*/
QueueAsyncClient(AzureQueueStorageImpl client, String queueName) {
Objects.requireNonNull(queueName);
Copy link
Member

Choose a reason for hiding this comment

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

This check should be in QueueServiceClient as it allows for a null queue name to be passed, the builders should already be checking for this.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

All the entries which asked the queueName will fall into this constructor.
I think it is better to have null checking here and remove the one in buildAsyncClient.

Copy link
Member

Choose a reason for hiding this comment

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

While that is true, having it remain in each individually will offer a closer indication to what went wrong and in the case of the client builder it will early out much sooner.

primaryQueueServiceClient = queueServiceBuilderHelper(interceptorManager).buildClient()
}

def "Get queue client from queue service client"() {
Copy link
Member

Choose a reason for hiding this comment

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

I haven't found it yet, so correct me if I'm wrong, but there used to be a similar test as this one but it would make a service call to the queue it got to show that getQueueClient/getQueueAsyncClient doesn't create the queue in the service. If that test doesn't exist could we change this test to do that?

@sima-zhu
Copy link
Contributor Author

Let's try to remove as much JUnit as we can and make sure we don't have collisions during concurrent live test runs. Overall it is looking good.

Valid point on live test collisions.
I am going to send final commit on JUnit deletion to avoid large diff.

@sima-zhu sima-zhu requested a review from alzimmermsft August 15, 2019 16:47
Copy link
Member

@alzimmermsft alzimmermsft left a comment

Choose a reason for hiding this comment

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

LGTM

Just make sure to give the tests one more run for validation before merging in.

@sima-zhu sima-zhu merged commit 6eb9e89 into Azure:master Aug 15, 2019
@sima-zhu sima-zhu deleted the storage_test branch August 15, 2019 21:10
pull bot referenced this pull request in AzureSDKAutomation/azure-sdk-for-java Aug 15, 2019
* Migrate queue to spock test framework

* Remove all Junit tests and dependencies
pull bot pushed a commit to test-repo-billy/azure-sdk-for-java that referenced this pull request Aug 15, 2019
* Migrate queue to spock test framework

* Remove all Junit tests and dependencies
pull bot pushed a commit to test-repo-tih/azure-sdk-for-java that referenced this pull request Aug 15, 2019
* Migrate queue to spock test framework

* Remove all Junit tests and dependencies
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