This script is only used in Linux-related workflows and is recommended to be placed in the /pkg/linux/ directory

run-unit-tests.sh is also for Linux.

Yes, But docker-load-test and load-test.sh are only used to test Linux-related in workflows.

But pkg/linux directory should represent packaging the Node.js client on Linux. The script here is to test load_test.js on Linux systems.

Assuming there are 3 scripts (e.g. load-test-win.sh, load-test-osx.sh, load-test-linux.sh) that test load_test.js on Windows, macOS and Linux. Do you think it's better to put these scripts under three different directories like pkg/windows, pkg/linux/ and pkg/macos?

IMO, It's good to:

• Put load_test.js under tests/linux
• Rename load_test.js with linux_load_test.js

It's bad to put load_test.js under pkg/linux.

I cannot see the difference between "verify" and "test". The only reason I can see for why you want to name it as "verify" is, you do not want to put test scripts under tests/ directory.

It's very clear that:

• pkg/ directiory contains scripts that package the Node.js binaries in various operation systems.
• src/ directory containes source code
• docs/ directory contains documents
• example/ directory contains examples
• tests/ directory contains tests

I do not know why do you so insist on distributing tests to different directories.

Some languages tend to put tests under the same directory with the code to test, like Golang, the source code directory contains xxx.go and the associated test xxx_test.go. It seems that your logic looks like that: the tests (load-test.sh) for package scripts should be put under the same directory (pkg/linux/*.sh). However, Node.js is different with those languages. Just like Java, the tests for source code (src/) are put under a separated directory (tests/). If you changed the rule, the for users new to this project, it's not clear to know tests are distributed into how many directories..

I don't want to play word games like "verify" and "tests", but since you mentioned this idea, I found a reference here: https://www.quora.com/What-is-the-difference-between-testing-and-verification

Verification: Before a system is developed, there must be a design where the basic requirements for the system are well spelt out. verification is concerned with whether the system is well-engineered, error-free, and so on. Verification will help to determine whether the software is of high quality.
Testing refers to the process of executing an application or program with the intent of detecting potential software bugs. It also has the objective of helping the developers to find out whether the software is working according to the intended purpose.

The load-tests.sh should be executed after the binaries are built and it tests whether the binaries can be executed in a given docker container.

I realized https://github.com/apache/pulsar-client-python/blob/main/pkg/test-wheel.sh might inspire you to put scripts under the pkg/ directory. I don't think it's a good practice.

First, in this script, /pulsar-client-python/wheelhouse/pulsar_client-*.whl should be the paths inside a docker container. This script cannot be executed locally. It's more like the docker-load-test.sh in this PR.

However, the path of docker-load-test.sh is not related to the Dockerfile under pkg/linux. Instead, the path of /pulsar-client-node/build/Release/pulsar.node and /pulsar-client-node/pulsar-client-node.tar.gz are created by load-test.sh, not the pkg/linux/Dockerfile_linux_glibc.

Well, In short. My point is to verify pulsar.node does not belong to the unit test. Although it is important, it is part of the compilation.

Let's go on and stop tangling.