feature: tests for JOBS plugin status and readiness

[Kaspiman]

Reason for This PR

roadrunner-server/jobs#81

Description of Changes

Improved tests check the status and readiness of the "Jobs" plugin

License Acceptance

By submitting this pull request, I confirm that my contribution is made under
the terms of the MIT license.

PR Checklist

[Author TODO: Meet these criteria.]
[Reviewer TODO: Verify that these criteria are met. Request changes if not]

• All commits in this PR are signed (git commit -s).
• The reason for this PR is clearly provided (issue no. or explanation).
• The description of changes is clear and encompassing.
• Any required documentation changes (code and docs) are included in this PR.
• Any user-facing changes are mentioned in CHANGELOG.md.
• All added/changed functionality is tested.

[rustatian]

Do not forget to sign your commits git commit -s or git commit -S (if you use a certificate) 😉

[Kaspiman]

@rustatian Job is done. Now i have only one failed test because of PR is not merged yet

[rustatian]

Hey @Kaspiman 👋🏻
I'm not sure about this PR. My concerns:

• Mixed HTTP/RPC tests in a single bundle. Should not be this way. Previous tests may be slightly refactored, but not changed, to keep track of possible issues with older versions.
• Timeouts. What if the timeout happens for some other reason? The test will treat that case as OK.
• 2.9.0 and other tags should also not be changed to maintain compatibility with the config plugin logic.

Could you please undo the changes (you could refactor the tests slightly) and add the actual test as a new one.

[Kaspiman]

Hey @Kaspiman 👋🏻 I'm not sure about this PR. My concerns:

• Mixed HTTP/RPC tests in a single bundle. Should not be this way. Previous tests may be slightly refactored, but not changed, to keep track of possible issues with older versions.
• Timeouts. What if the timeout happens for some other reason? The test will treat that case as OK.
• 2.9.0 and other tags should also not be changed to maintain compatibility with the config plugin logic.

Could you please undo the changes (you could refactor the tests slightly) and add the actual test as a new one.

Returned almost everything back and added only a positive readiness test. I remember these requirements, I will follow them further.

Why did I decide to mix everything up and remove the repetitions? Tests now consist almost entirely of repetitive code. 5-10 lines of checks require 30-40 lines of the boilerplate. The situation becomes more complicated due to different versions of the config and the RR itself. I want to simplify the process of launching RR and avoid unnecessary code. Any thoughts on how to do this?

[rustatian]

Hey @Kaspiman 👋🏻 I'm not sure about this PR. My concerns:

• Mixed HTTP/RPC tests in a single bundle. Should not be this way. Previous tests may be slightly refactored, but not changed, to keep track of possible issues with older versions.
• Timeouts. What if the timeout happens for some other reason? The test will treat that case as OK.
• 2.9.0 and other tags should also not be changed to maintain compatibility with the config plugin logic.

Could you please undo the changes (you could refactor the tests slightly) and add the actual test as a new one.

Returned almost everything back and added only a positive readiness test. I remember these requirements, I will follow them further.

Why did I decide to mix everything up and remove the repetitions? Tests now consist almost entirely of repetitive code. 5-10 lines of checks require 30-40 lines of the boilerplate. The situation becomes more complicated due to different versions of the config and the RR itself. I want to simplify the process of launching RR and avoid unnecessary code. Any thoughts on how to do this?

Yeah, these tests looks very similar to each other and you're right, there is a lot of boilerplate.

Since this is international tests, would be nice to have one instantiation point (endure + error loop) and perform several tests on that point. We might use max_jobs: 0 to be sure, that the worker is fresh between the requests. Example:

func TestServiceInit(t *testing.T) {
	cont := endure.New(slog.LevelDebug)

	cfg := &config.Plugin{
		Version: "2.9.0",
		Path:    "configs/.rr-service-init.yaml",
		Prefix:  "rr",
	}

	err := cont.RegisterAll(
		cfg,
		&logger.Plugin{},
		&service.Plugin{},
	)
	assert.NoError(t, err)

	err = cont.Init()
	if err != nil {
		t.Fatal(err)
	}

	ch, err := cont.Serve()
	assert.NoError(t, err)

	sig := make(chan os.Signal, 1)
	signal.Notify(sig, os.Interrupt, syscall.SIGINT, syscall.SIGTERM)

	wg := &sync.WaitGroup{}
	wg.Add(1)

	stopCh := make(chan struct{}, 1)

	go func() {
		defer wg.Done()
		for {
			select {
			case e := <-ch:
				assert.Fail(t, "error", e.Error.Error())
				err = cont.Stop()
				if err != nil {
					assert.FailNow(t, "error", err.Error())
				}
				return
			case <-sig:
				err = cont.Stop()
				if err != nil {
					assert.FailNow(t, "error", err.Error())
				}
				return
			case <-stopCh:
				err = cont.Stop()
				if err != nil {
					assert.FailNow(t, "error", err.Error())
				}
				return
			}
		}
	}()

	time.Sleep(time.Second * 10)
	t.Run(test1())
        t.Run(test2())
        ....
        t.Run(testN())
	stopCh <- struct{}{}
	wg.Wait()
}

In the plugins section we might add all needed plugins. So likely, most of the boilerplate might be significantly reduced. Unfortunately, I don't have enough time, but with this idea, if you have time, you might update tests one-by-one.

[rustatian]

Thanks @Kaspiman 👍🏻

[rustatian]

Some tests, for example for the RR version in the configuration plugin might be moved from integrational to unit, to the config plugin.

[rustatian]

Some tests it won't be possible to reduce, for example, server tests where we testing different transport. In that case, you have to have all tests cases for the 3 different transports (pipes, unix sockets, tcp sockets).