-
Notifications
You must be signed in to change notification settings - Fork 13
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
PRO-2913: add writing tests for modules documentation #237
base: main
Are you sure you want to change the base?
Conversation
PRO-2913 Add documentation about testing modules
At the moment there is no documentation explaining how to test apostrophe 3 modules. The goal is to add it to the apostrophe guides or cookbooks. |
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.
Overall, this is a preliminary review. I've indicated areas where I think this needs additional content. What you have written so far will need some light editing, but I didn't want to go through it too carefully until you've fleshed out the additional content, potentially changing the existing content.
describe('%module-name%', function () { | ||
let apos; | ||
|
||
this.timeout(t.timeout); |
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.
Do you need to set the environment variable to use t.timeout
?
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, there is more on that below in the file https://github.com/apostrophecms/a3-docs/pull/237/files#diff-fb2950150785db8f273073724f8a9db63c2d3425609707858da4688a226ea278R138
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 you add another code comment if this is optional or not and maybe be more explicit in your 'Output' section about the steps to run the test. So do you normally use export TEST_TIMEOUT=5000
, and then npm test
, or feed it in directly?
@BoDonkey I've changed the example from sitemap to login-hcaptcha. I didn't work as expected with sitemap for some reasons. |
|
||
This documentation focuses on how to test Apostrophe modules, not Apostrophe itself using integration testing. | ||
|
||
Modules should be stand-alone npm packages. |
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 expand this to something like: "Modules should be stand-alone npm packages. They need to be hosted somewhere that our testing can access. For this example, we are hosting this module in a github repo. We will use a fictitious module named article
to illustrate how to write tests for modules."
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.
My bad -> "github" -> "GitHub"
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.
Getting closer. Just needs a little fleshing out to help people understand how to better extend tests.
* main: (28 commits) fix missing async small corrections add further comment edits add images and change text rearrangement and corrections based on comments comment changes Add "showQuery" documentation in docs/reference/modules/piece-page-type.md add missing word update with comment corrections fix typo text changes from second comments further text changes comment changes additional editing change admin addition changes based on comments and additional content finish TOC and end section fix sidebar Add to sidebar add initial page ...
}; | ||
|
||
// describe and it functions are provided by mocha | ||
// Usually use to "structure" the test file |
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.
"use" -> "used"
// Usually use to "structure" the test file | ||
// They don't have a strict meaning from mocha's point of view | ||
|
||
// describe is a test suite and used to group tests |
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.
"...suite and is used..."
describe('article', function () { | ||
let apos; | ||
|
||
this.timeout(t.timeout); |
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 you add a comment about whether this is optional and that you need to set an environment variable? I know you have a description of setting it below, but a reminder here would be good.
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.
Almost there, just a few grammatical errors (some my fault) and I think a need for a little clarification. There is also the topic I started on Slack with respect to where in the Guide we should have your article.
Tests are useful to guarantee that the requirements of your application are met over time. | ||
They also ensure that code changes don't generate breaking artifacts. | ||
|
||
Automating tests for expected scenarios saves significant time over having to mock those same scenarios manually each |
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.
"Mocking" is usually a thing that happens inside automated tests, so this sentence doesn't make sense to me as written. Maybe just end with "... over having to manually execute a regression test plan each time there are code changes."
|
||
This documentation focuses on how to test Apostrophe modules, not Apostrophe itself using integration testing. | ||
|
||
Modules should be stand-alone npm packages. They need to be hosted somewhere that our testing can access. For this |
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 don't think our docs cover turning Apostrophe modules into npm packages in general yet. And I think a lot of people reading this page will want to know about how to write integration tests for their project-level modules. Maybe we're not ready to address that yet but I think it's probably the more common use case for our audience.
I'm not saying we can't get this article out there, but we should follow up with a page about how to publish your open source apostrophe module, and an update to this page to cover integration tests for project level modules.
- [eslint-config-apostrophe](https://www.npmjs.com/package/eslint-config-apostrophe): *An ESLint configuration for ApostropheCMS core and officials modules* | ||
- [mocha](https://www.npmjs.com/package/mocha): *Simple, flexible, fun JavaScript test framework for Node.js & The Browser* | ||
```sh | ||
npm install --save-dev apostrophe eslint eslint-config-apostrophe mocha |
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.
Linting and integration testing aren't the same thing. Should we acknowledge this somewhere, maybe mention we're including linting too and what that gets us?
</template> | ||
</AposCodeBlock> | ||
|
||
Add the following to `.eslintrc.json` to tell eslint to use ApostropheCMS ESLint confiuration. |
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.
Good chance to say why and what this gets us.
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 think an additional sentence here or below the code block at around line 77 should be added. Something like:
"While not strictly part of integration testing, running ESLint alongside the Mocha test(s) reduces potential code error and ensures your module code conforms to the style of other Apostrophe modules."
Note: I'm not sure if this is the most accurate statement. You might want to edit it.
```json | ||
{ | ||
"/**": "This package.json file is not actually installed.", | ||
" * ": "Apostrophe requires that all npm modules to be loaded by moog", |
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.
Don't mention moog. Just say "npm modules to be loaded"
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.
Our v3 docs don't talk about moog, it's an internal detail for us to worry about; they talk about apostrophe modules and how they are loaded but this is no longer a "brand" we use.
* main: (61 commits) Resolve addition to conditional fields section of A3 docs good doc link fixed broken links, added missing link further comment edits Updates based on first comments changes based on comments slight edit add documentation for rebundleModules modifies the guide page edit based on comments response to comments and adds stream monor change change login reference add apiRoutes section fix heroku link errata all but apiRoutes further edits sending email init changes in response to comments ...
* main: (28 commits) rearrange and add new option edit in response to comments edits in response to comments edits in response to first comments add link and anchor info minor correction to code example and file location changed wording minor wording change remainder of command menu doc add new page to sidebar response to comments updates example and link for authentication API Further comment responses further comment edits further corrections changes in response to comments add new GA4 tag and remove unsupported tag manager adds clarity tag corrects template slot required comment ...
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 have a few minor changes/points. I'm not sure if Tom will chime back in with additional chages.
</template> | ||
</AposCodeBlock> | ||
|
||
Add the following to `.eslintrc.json` to tell eslint to use ApostropheCMS ESLint confiuration. |
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 think an additional sentence here or below the code block at around line 77 should be added. Something like:
"While not strictly part of integration testing, running ESLint alongside the Mocha test(s) reduces potential code error and ensures your module code conforms to the style of other Apostrophe modules."
Note: I'm not sure if this is the most accurate statement. You might want to edit it.
|
||
We will start with a single test file `test/index.js`. | ||
|
||
As your test grows, you can break them down into multiple files based on your liking. |
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.
"As your test grows, you can break it down into multiple files based on your liking."
|
||
### Output | ||
|
||
By running the test using the example `@apostrophecms/login-hcaptcha` module details and the `npm test` command, you should see the output below |
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 think this is confusing. First, you've set up to run the tests using the hypothetical article module. I realize that you include the example URL for '@apostrophecms/login-hcaptcha`, but sticking with the one example the whole way through is less confusing. Second, that module has a lot of tests. I'm worried that if the end reader attempts to run the tests for themselves with the actual module, the output will be significantly different and confusing. I would actually mockup the expected results from running this on the example module.
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'm OK with you guys taking this the rest of the way.
What happened to this PR? |
Summary
Add
Writing tests for modules
documentationWhat are the specific steps to test this change?
What kind of change does this PR introduce?
(Check at least one)
Make sure the PR fulfills these requirements:
If adding a new feature without an already open issue, it's best to open a feature request issue first and wait for approval before working on it.
Other information: