-
Notifications
You must be signed in to change notification settings - Fork 962
Integration Test Refactor #131
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
Conversation
WIP: fiddling with Travis YML Jobs WIP: refactor build matrix WIP: remove integration tests (Will reimpl) WIP: remove files that snuck in WIP: remove unneeded arg WIP: add node_modules bin to path fix(*): remove project config (intended to be supplied) WIP: reset TEST_ENV for int tests WIP: update Travis yarn dep WIP: use before_install script instead of install script
WIP: reimplement browserify/webpack integration tests WIP: fiddling with int test CI WIP: build matrix for Integration tests (parallelize those jobs too) WIP: trying to parallelize int tests WIP: remove unneeded env assignment WIP: blahhh... WIP: should work... WIP: removing env WIP: removing test harness I haven't started yet test(typescript): add typescript namespace tests
@sphippen I discovered an implicit dependency in the storage codebase that I addressed here as it was breaking tests when not all tested together. PTAL |
778fd7d
to
16d9761
Compare
a9a2284
to
aaa3485
Compare
.travis.yml
Outdated
- export PATH=$PATH:./node_modules/.bin | ||
- mkdir -p tests/config && echo "$PROJECT_CONFIG" > tests/config/project.json | ||
script: | ||
gulp test --suite="$TEST_SUITE" --env="$TEST_ENV" |
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.
TEST_SUITE doesn't seem to be defined anywhere
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.
Another good catch, thanks!
@@ -14,7 +14,7 @@ | |||
* limitations under the License. | |||
*/ | |||
|
|||
importScripts('../../../dist/package/firebase-app.js'); | |||
importScripts('./node_modules/firebase/firebase-app.js'); |
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.
why use the node_modules instance of firebase here? Would have thought you'd need this to be dist
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.
I npm install
the firebase package that we build in dist
here so we can consume it as a third party would for the test.
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.
Are you running npm link
first? While I follow the logic, I can see this magic biting someone later on.
@@ -0,0 +1,42 @@ | |||
#!/bin/bash |
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.
could this just be a gulp task with multiple steps?
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.
Yes and no. I opted to use bash instead as gulp pipelines discourage the use of "temp" directories which is what makes this flow so consistent. I could do that in gulp but it would be going against a best practice.
In addition, not everyone will be consuming the SDK via gulp and not all of the scripts will be possible in gulp (e.g. reactnative/cordova testing which is soon to come) so I lean towards bash for this.
@@ -78,6 +77,7 @@ describe('Firebase Storage > Request', () => { | |||
const expectedHeaders = {}; | |||
expectedHeaders[requestHeader] = requestValue; | |||
expectedHeaders[versionHeaderName] = versionHeaderValue; | |||
console.log(args[4], expectedHeaders); |
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 and the follow log can be deleted.
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.
Great catch, thank you!
…veraging their own binaries
fbcf52c
to
64f39ff
Compare
refactor(quickstart-tests): refactor to use FIREBASE_PROJECT as an env var rather than an arg fix(tests): ensure that the wdio binary is pointing to the proper location fix(deps): add dep to quickstart package.json refactor(deps): move ts-node dep to devDeps fix(quickstart-tests): run tests on saucelabs WIP: refactor to remove reload (causing flakiness issues) refactor(quickstart): refactor to only navigate to the base URL instead of reloading the page fix(quickstarts): fix timing issue with reloads WIP: try limiting the scope to the :first-child WIP: refactor the tests to reference the intended post directly rather than indirectly. WIP: refactor to not iterate
7fe90b7
to
c0e76f9
Compare
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.
The Storage change looks good (I should actually trim some of that code, since it's leftover from internal use, irrelevant for the public SDK).
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.
Took a high-level look at the shell scripts and config files.
|
||
# Misc Addons/Configs | ||
dist: trusty | ||
sudo: required |
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.
Why is sudo
required?
- npm install -g yarn | ||
before_script: | ||
- export PATH=$PATH:./node_modules/.bin | ||
- mkdir -p tests/config && echo "$PROJECT_CONFIG" > tests/config/project.json |
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.
How does PROJECT_CONFIG
get initialized?
|
||
## Authoring an Integration Test | ||
|
||
The point of the integration tests is to be as flexible as possible. The only convention that I would recommend is supplying a `runner.sh` file to do the actual work of the test. |
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.
we recommend
- Service Worker Integration | ||
- Compatability with Webpack/Browserify/Typescript etc | ||
- High level UI testing | ||
- Others with same kinds of environmental restriction |
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.
restrictions
That said, if you are looking for a pattern to follow, the process that was followed for several of the tests, is outlined below: | ||
|
||
- Copy the test files to a temporary working directory | ||
- Setup an `EXIT` trap to cleanup the temporary directory at the end of the script |
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.
Can we provide a reusable bash function in shared
for this?
- `npm install` the folder `dist/package`, this allows the test to function as if the SDK was installed from NPM | ||
- (For tests that are only validating the firebase namespace) copy the `shared` directory above into the working directory | ||
|
||
The tests are then ran with karma/mocha/webdriver.io/selenium or whatever else you need to accomplish the purpose of your test. Each of these runners requires their own config (and sometimes their own dependencies), supply these config files directly in the test directory (e.g. many of the suites have their own package.json) as the tests are meant to be isolated from each other as much as possible. |
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.
... own dependencies). Supply these config...
@@ -0,0 +1,45 @@ | |||
#!/bin/bash |
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.
Might be a good idea to do set -e
in these bash scripts so that any errors will trigger an early exit.
@@ -0,0 +1,3 @@ | |||
{ | |||
"text": "Lorem ipsum dolor sit amet, consectetur adipiscing elit. Praesent tempor elit mi, nec ullamcorper neque lacinia vitae. Nulla porttitor ac mauris a mollis. Praesent pellentesque lacinia metus, in commodo risus vulputate eget. Vestibulum volutpat ullamcorper porta. Phasellus fringilla faucibus nisi, at sodales dolor maximus nec. Integer quis purus sed urna viverra pellentesque. Suspendisse potenti. Phasellus lobortis sagittis metus quis accumsan. Suspendisse pulvinar pretium mauris, quis congue risus scelerisque ac. Morbi quis placerat ante, in congue elit. Suspendisse et enim dictum, varius est quis, hendrerit nibh. Fusce vitae molestie sapien. Duis finibus cursus quam sed blandit." | |||
} |
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.
Add new line. Here and in other affected files.
This is a wholesale refactor of the integration test harnesses to better isolate them from the rest of the SDK testing.
Each suite can leverage the files found in
integration/shared
which is a spec file of the SDK (built from the existing specfiles) and a simple validator. I then run a suite of tests that validates the SDK in each of its consumption mechanisms. We can add more as needed (e.g. reactNative, cordova) and as each directory's tests are run by hand (i'm currently providing arunner.sh
file for the existing tests) it can be used to simulate whatever environment.Once Travis CI supports build matrices in secondary jobs the CI for this will get even simpler. Until then we have a little manual work which isn't that bad as I don't really want to have an overabundance of fragile Integration testing.
I will flesh out the README.md to detail the specfile (i.e.
integration/shared/namespaceDefinition.json
and how the integration tests are to be written)