Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(tests): test default modules availability #403

Merged
merged 6 commits into from
Feb 8, 2024
Merged

Conversation

Frzk
Copy link
Contributor

@Frzk Frzk commented Jan 22, 2024

Test availability of (what we consider) default modules for PHP.

We currently don't support specifying a precise version for these modules. We just ship the latest version we have. So the test is rather simple: just list available PHP modules and check we have everything.

The list of default modules will have to be maintained (or put somewhere else?)

Also:

  • refactor code in test::helpers::test_compile
  • add an explanation message when skipping tests

We currently don't support specifying a precise version for these
modules. We just ship the latest version we have. So the test is rather
simple: just list available PHP modules and check we have everything.

The list of default modules will have to be maintained (or put somewhere
else?)

Also:
- refactor code in `test::helpers::test_compile`
- add an explanation message when skipping tests
@Frzk Frzk self-assigned this Jan 22, 2024
@Frzk Frzk marked this pull request as ready for review January 23, 2024 08:08
@Frzk Frzk requested a review from EtienneM January 23, 2024 08:15
test/helpers Outdated Show resolved Hide resolved
test/helpers Outdated Show resolved Hide resolved
test/helpers Outdated Show resolved Hide resolved
Frzk and others added 3 commits January 24, 2024 11:15
Co-authored-by: Étienne M. <EtienneM@users.noreply.github.com>
Refactor code to make it easier to test a full deployment.

- leverage shUnit2's `setUp` and `tearDown` functions to setup a few things
- also introduce a `test::utils::setupFixture` function that copies a
  fixture into the container's HOME directory. This follows advice from
  shUnit2's developer: kward/shunit2#46
- add a more precise namespace to `test::` functions
- introduce new tests (`test::legacy::php8x`)
@Frzk Frzk requested a review from EtienneM January 25, 2024 17:43
test/tests Outdated
Comment on lines 19 to 20
test::legacy::defaults() {
# Test a deployment of a legacy app (not using Composer)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

issue(non-blocking): that may seem a bit picky but I find it important. I don't really like the word "legacy". Not using Composer is not exactly legacy. We named it "Classic" in the buildpack so I would stick with this naming.

Copy link
Contributor Author

@Frzk Frzk Jan 26, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure. I chose "legacy" because it's how we call it in our documentation 😄
I'll open an issue to homogenize this to "classic" (and I'll modify the name in this PR).
I will handle it while handling this issue: Scalingo/documentation#2378

test/helpers Outdated Show resolved Hide resolved
Copy link
Member

@EtienneM EtienneM left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is really great. I still have a question about the comment sothat we are sure that it's understand-able. But otherwise LGTM :)

test/helpers Outdated
Comment on lines 6 to 12
# Deploy a PHP app in a Scalingo runtime and test that everything is as
# expected. The different fixtures allow us to test different setup and
# conditions.

old_home="${HOME}"
local fixture_name="${1}"
local detect_expectation="${2}"
local version="${3}"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

issue: by reading these lines, it's not really clear what the 3 variables should contain. Could you make it explicit in the comment? Especially because of the version variable that does not seem to contain a complete version which seems really odd

@Frzk Frzk requested a review from EtienneM February 7, 2024 14:28
Copy link
Member

@EtienneM EtienneM left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome, thanks for the comprehensive comment

@Frzk Frzk merged commit 2eade4d into master Feb 8, 2024
2 checks passed
@Frzk Frzk deleted the feat/364/testing branch February 8, 2024 08:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants