-
Notifications
You must be signed in to change notification settings - Fork 35
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
Conversation
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
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`)
…into feat/364/testing
test/tests
Outdated
test::legacy::defaults() { | ||
# Test a deployment of a legacy app (not using Composer) |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this 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
# 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}" |
There was a problem hiding this comment.
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
As per suggested by @EtienneM during review.
There was a problem hiding this 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
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:
test::helpers::test_compile