feat: add a more robust set of tests

[hanoii]

Adding something more useful in terms of test coverage, for now this adds:

Different drupal version and a smaller set of tests are run by GHA strategy matrix

• a very bear dummy drupal module instead of relying on keycdn
• tests if the module has no composer ddev poseer should still work
• with both d10 and 11 of core supported versions tests that:
  • it installs
  • ddev poser works
  • ddev symlink-project works
  • the core version install is the one specified
  • php tests comamnds are available
  • node commands are available

What I like to add in this initial approach is that eslint and stylelint actually does something, but that can be added later.

~The tests will fail until #81 and #80 are accepted.~ They are in, tests should now be green

[hanoii]

rebased, and try a fix as something was failing

[hanoii]

tests are green

[weitzman]

LGTM.

I have done it in a while, but I want to make sure our tests can still pass locally. Could you please check that and document at the bottom of the README that command to run?

[hanoii]

@weitzman I did run the tests manually several times but in testing this again I noticed some potential issues by not using the new TEST_DRUPAL_CORE env var.

I fixed this and now just running it locally works and uses the core default.

Added to the readme, latest version can be read on https://github.com/hanoii/ddev-drupal-contrib/blob/tests-rehaul/README.md#add-on-tests

EDIT: Added some small tweaks to the test

[hanoii]

Still doing some work

[hanoii]

@weitzman it's ready for review, I decided to use git submodule for ~bash~ bats, see https://github.com/ddev/github-action-add-on-test/issues/36, but no change on the ddev bats github action is needed hanks to disable_checkout_action.

My rationale for this is that it's a lot easier to install and to depend on things like bats-assert. Updated the README but the gist to run this locally is:

git submodule update --init
./tests/bats/bin/bats tests

Hope you like it, it was quite a bit of work getting it right!

EDIT: commands simplification

[weitzman]

Any feedback, @rfay @tyler36?

[hanoii]

@rfay

I'm pretty sure we don't need specialty handling for d10/d11.

It's true that currently there's no difference, but... I did experience an issue: #82, while not with the functionality, the way it was suggested to install yarn, didn't work as is with d11.

I figured it wasn't bad that we have both cores. And with that, I am also testing the ability to change cores and making sure that's being picked up.

[hanoii]

Most suggestion were addressed but one which I followed up. Thanks

[rfay]

My suggestion of ddev config --auto was based on the assumption that the code is already laid down; it works well in that situation. DDEV detects docroot and subversion of drupal and does the right thing with corepack, etc. So I wasn't saying "don't test both d10 and d11", I was saying that if you like it, you can use DDEV's auto-config that detects and makes the right choices.

[hanoii]

but the code is not already layed out in the context of that test, as we are testing adding the core later on as part of ddev poser

[hanoii]

I was going to add some thoughts on the git submodules discussion, only because I feel it's interesting... but added it to https://github.com/ddev/ddev-addon-template/issues/62 instead

[rfay]

If the code isn't there yet, then using ddev config to add hints of what's going on is a great technique, as in the quickstarts, which do the config before the composer create-project. https://ddev.readthedocs.io/en/stable/users/quickstart/#drupal