Migrate e2e tests for RabbitMQ to Go.

[v-shenoy]

Signed-off-by: Vighnesh Shenoy vshenoy@microsoft.com

Provide a description of what has been changed

Checklist

• Commits are signed with Developer Certificate of Origin (DCO - learn more)
• Tests have been added

Fixes #3249

Relates to #2737

[v-shenoy]

/run-e2e rabbitmq
Update: You can check the progress here

[zroubalik]

Looking good, just a nit: I would move all test .go files into one package (rabbitmq) together with rabbitmq_helper.go.
I don't think we need to create a separate package for each one, or is there any reason?

Also, do you think that you can add activation for this scaler (a separate PR is fine)?

Thanks

[v-shenoy]

Looking good, just a nit: I would move all test .go files into one package (rabbitmq) together with rabbitmq_helper.go. I don't think we need to create a separate package for each one, or is there any reason?

The only reason I have them in a separate package is because each test has variables like testNamespace, scaledObjectName. If they're in the same package they conflict with one another (this is also why actually each test is in its own package, ideally, I would want to have all of them under scalers_go directly)

The solution is to have them use names like testNamespaceHTTP or testNamespaceAMQP etc but I don't particularly like that solution.

[v-shenoy]

Also, do you think that you can add activation for this scaler (a separate PR is fine)?

Thanks

This is already being done in #2831. I didn't want to duplicate the work.

[zroubalik]

Looking good, just a nit: I would move all test .go files into one package (rabbitmq) together with rabbitmq_helper.go. I don't think we need to create a separate package for each one, or is there any reason?

The only reason I have them in a separate package is because each test has variables like testNamespace, scaledObjectName. If they're in the same package they conflict with one another (this is also why actually each test is in its own package, ideally, I would want to have all of them under scalers_go directly)

The solution is to have them use names like testNamespaceHTTP or testNamespaceAMQP etc but I don't particularly like that solution.

Hm, so can we put all these packages under rabbitmq package? I'd like to have all tests related to one scaler in one package.

scalers_go/rabbitmq/rabbitmq_helper.go
scalers_go/rabbitmq/rabbitmq_queue_amqp/rabbitmq_queue_amqp_test.go
scalers_go/rabbitmq/rabbitmq_queue_http/rabbitmq_queue_http_test.go
scalers_go/rabbitmq/rabbitmq_...

[v-shenoy]

Looking good, just a nit: I would move all test .go files into one package (rabbitmq) together with rabbitmq_helper.go. I don't think we need to create a separate package for each one, or is there any reason?

The only reason I have them in a separate package is because each test has variables like testNamespace, scaledObjectName. If they're in the same package they conflict with one another (this is also why actually each test is in its own package, ideally, I would want to have all of them under scalers_go directly)
The solution is to have them use names like testNamespaceHTTP or testNamespaceAMQP etc but I don't particularly like that solution.

Hm, so can we put all these packages under rabbitmq package? I'd like to have all tests related to one scaler in one package.

scalers_go/rabbitmq/rabbitmq_helper.go
scalers_go/rabbitmq/rabbitmq_queue_amqp/rabbitmq_queue_amqp_test.go
scalers_go/rabbitmq/rabbitmq_queue_http/rabbitmq_queue_http_test.go
scalers_go/rabbitmq/rabbitmq_...

Yeah, we can. Point to note, we haven't done this for other scalers having multiple tests (such as service bus, or external scaler. Do those need to be changed as well, or it's only because RMQ has so many?

[v-shenoy]

/run-e2e rabbitmq
Update: You can check the progress here

[zroubalik]

Yeah, we can. Point to note, we haven't done this for other scalers having multiple tests (such as service bus, or external scaler. Do those need to be changed as well, or it's only because RMQ has so many?

You are right. We've just discussed this with @JorTurFer and have agreed that we should group all relevant scaler families. So for example all AWS under aws, Azure under azure etc.