Add testing information

[MorningLightMountain713]

Adds an images directory under tests.

Maybe we can get some fresh png(s) from marketing to update the repo? (I've just referenced the main flux_banner.png)

I'm not sure how you all run your tests, or what workflows you use. I've struggled in this area and my testing has been quite janky. I couldn't find any documentation for testing procedure, so I went out on a limb and wrote my own.

Basically, it builds / runs a few containers, mounts your docker socket and local repo dir, then runs all the tests as the fluxtesting user in an ubuntu container. (while proxying the docker socket from a socat container, to allow for running as non root)

Tested on both macOS and Ubuntu.

Have a look at the readme: tests/images/README.md, describes how to run the tests and some notes etc.

Allows for rapid prototyping as you can modify the code then run the tests immediately, and single out tests etc.

As npm install can take significant time, package.json is hashed so it doesn't have to run the installer on every run (first time is mandatory)

A few of things to note:

• A lot of the tests were opening hundreds of connections to the db as they were calling initiateDB on every test, which was opening a new connection instead of using the existing connection pool. So I've added to open a DB connection if there isn't one already existing. (As the mongo client handles connection pooling, reconnection etc).
• Have added a .mocharc.json file with a require that sets up the global.userconfig this was in some of the tests as a require and in others it wasn't. Meaning that if all the tests were run, it was fine. However if you ran some modules individually they would fail, as they weren't pulling in the require. (eg dockerService.test.js) I've since removed the requires from all the tests as this is required globally via .mocharc.json.
• Changed one of the docker tests to ignore images that didn't have repo tags, as this was failing locally as I have some homemade images that wern't tagged and the array index lookup was breaking the test.
• Changed one of the tests to use os.homedir instead of many relative ../, this was meaning that flux HAD to be installed two directories below the homedir for testing, now it can go anywhere.
• Add eslint igmore for dev folder, so I can have a local dev folder that won't be linted.

dbHelper.js change:

 async function initiateDB() {
-  openDBConnection = await connectMongoDb();
+  if (!openDBConnection) openDBConnection = await connectMongoDb();
   return true;
 }

I've tested this on a live node and can see still getting connection pooling etc:

test> db.serverStatus().connections
{
  current: 10,
  available: 51190,
  totalCreated: 75,
  active: 3,
  threaded: 10,
  exhaustIsMaster: 0,
  exhaustHello: 2,
  awaitingTopologyChanges: 2
}

macOS: (local development)

Ubuntu: (one of my local vm's)

[gitguardian]

⚠️ GitGuardian has uncovered 1 secret following the scan of your pull request.

Please consider investigating the findings and remediating the incidents. Failure to do so may lead to compromising the associated services or software components.

🔎 Detected hardcoded secret in your pull request

GitGuardian id	GitGuardian status	Secret	Commit	Filename
-		Generic High Entropy Secret	7c6a931	tests/unit/fluxCommunicationMessagesSender.test.js	View secret

🛠 Guidelines to remediate hardcoded secrets

1. Understand the implications of revoking this secret by investigating where it is used in your code.
2. Replace and store your secret safely. Learn here the best practices.
3. Revoke and rotate this secret.
4. If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.

To avoid such incidents in the future consider

• following these best practices for managing and storing secrets including API keys and other credentials
• install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.

---

<sup>🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.

Our GitHub checks need improvements? Share your feedbacks!</sup>

[MorningLightMountain713]

You can run single tests like this too (or modules without the -g switch):

davew@fdm:~/test_test/flux$ npm run test:zelback:unit:oneoff -- -g 'should remove a network' tests/unit/dockerService.test.js

[MorningLightMountain713]

Takes about 10 seconds from start to finish to build the test container and start them / run the tests; 7, if the other containers are already running.

[Cabecinha84]

Ack. Nice job!

[Cabecinha84]

this one is a nice catch.