[test] Integration test coverage

[codelipenghui]

Motivation

Improve integration test coverage https://github.com/apache/pulsar/tree/master/tests/integration
The integration test will run on a real cluster, not a mock environment like the unit test does.

Tools

• Integration test for client tool [improve][test] Add integration test for pulsar-client #17616
• Integration test for perf tool [fix][cli] Quit PerformanceConsumer after receiving numMessages messages #17750

Security

• Integration test for TLS [improve][test] Add integration tests for TLS #17141

Websocket service

• With broker [improve][test] Add integration test for websocket #17843
• With proxy [improve][test] Add integration test for websocket #17843
• Separated service [improve][test] Add integration test for websocket #17843

Plugins

• Integration test for Protocol handlers [improve][test] Add integration test for protocol handlers #17350 @andrasbeni
• Integration test for Broker interceptors [improve][test] Add integration test for broker interceptors #17515
• Integration test for Broker message filters [improve][test] Add integration test for entry filters #17396
• Integration test for Additional servlet (broker/proxy) [improve][test] Add integration test for additional servlets #17450

[codelipenghui]

@nodece Is handling the integration test of security

[andrasbeni]

@codelipenghui , can you please let me know what tests you would like to see for the admin CLI? As I can see, runAdminCommandOnAnyBroker does use the admin cli and is used extensively by integrations tests. And there are some more usages through the constant ADMIN_SCRIPT. So it's not a dedicated test, but I think it already has some coverage.

[codelipenghui]

@andrasbeni Most of the admin CLI integration tests are under tests/integration/cli and yes we already have some coverage for this part. I think we should also consider the improve the coverage for this part to avoid someone changing the output format or introducing new incompatible options. But it's not a very strong opinion, we need to maintain so many test codes in the future. WDYT?

[andrasbeni]

@codelipenghui , I believe integration tests are too expensive to do a full validation of output and command line parameters. Having taken a quick look at admin command implementations and PulsarAdminToolTest, it looks to me that admin commands are designed to be easily unit tested: the PulsarAdmin can be mocked by setting a Supplier and CaptureStdOut makes their output verifiable. So, in my opinion, we would be much better off writing unit tests for all these.

[codelipenghui]

@andrasbeni Sound good to me.