-
Notifications
You must be signed in to change notification settings - Fork 145
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: testing guidelines #377
feat: testing guidelines #377
Conversation
Update, fix and add to the current draft of the testing guidelines.
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.
Nice @ghinks !
Do you think it's worth moving this out of the /draft directory and removing the "draft" label from the Table of Contents here? Or do think there is still more to be done? (isn't there always 🙃 )
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.
These are great changes!
I think we should move it out. I have meeting later today and I’m hoping to get more contributors to go in after us. It’s never done done. |
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.
LGTM
docs/drafts/testing-guidelines.md
Outdated
@@ -16,7 +16,10 @@ The minimal versions you should focus are: | |||
* LTS (long time support) | |||
* Current | |||
|
|||
Of course, you are freely to maintain a package that run also with older versions of Node.js that reach the "end-of-life" stage. | |||
Of course, you are free to maintain a package that also runs with older versions of Node.js that have reached the "end-of-life" stage. |
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.
Perhaps something a bit stronger than "free to"? I'd personally prefer "encouraged to".
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.
agreed.
Alter the text so that we do not mention mocking and refer to remote services rather than external.
docs/drafts/testing-guidelines.md
Outdated
@@ -25,9 +28,31 @@ It is a good idea to have unit tests, coverage that matches most use cases for t | |||
* **integration test**: test your code with other applications dependencies | |||
* **acceptance test**: test your application sticks in performance, heavy load, etc.. | |||
|
|||
Here are some things to consider as you develop your package. | |||
#### Unit Testing |
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.
Should we not just link to something like https://martinfowler.com/bliki/TestPyramid.html?
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 am happy to add a link
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.
Sorry, wasn't sure - did you mean to do it in this PR or later?
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 will add a link later. If that is ok. This document is going to be revisited after I do the CI/CD document that this document will link to aswell.
docs/drafts/testing-guidelines.md
Outdated
|
||
For many packages integration testing requires that the built package be run via a testing tool upon several environments. The / | ||
field of continuous integration and deployment (CICD) is complex. The package being built shall be run through | ||
a CICD pipeline. Several integrations are available for GitHub based repositories. (There are also alternatives to 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.
Pet peeve, but CI/CD pipeline is so incredibly vague, that it can mean pretty much anything... While I'm not sure we need to include these details at all (nor that the definitions of unit vs integration matter that much at all, fwiw), I think we should still link to some examples or in depth articles on this.
I'd very much be in favor of how this is done in JS world, though! Possibly with a distinction on how you do certain things in node vs browser.
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.
Agreed. We even have the whole document on CI/CD dedicated to this subject.
For the testing document maybe we should reference our CI/CD draft.
What both yourself and @bnb have contributed to this document too.
I think we do need to have CI/CD Options documented.
- what can we do for free for an open source project
- what providers are there?
- what does each give us?
This is actually a pretty big area in both open source and the enterprise and I think we should talk about this as an item on 14th July in the Package Maintenance meeting.
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.
@dominykas are we ok referring to the CI/CD document. I agree that we need to give concrete examples of what is currently possible in that document and I intend to start that document next.
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, we can link and extend the existing doc. I'm just not entirely sure about the term "CI/CD pipeline" - it can mean a gazillion things to different people, so possibly we should simplify the wording towards something like "your tests should run automatically on pr/merge/commit/etc" and link to the doc?
It should not matter if it's a "pipeline" or a single job on Travis. It does not need to be complex. People need not be scared of testing and automation. The simpler the better, esp in the context of oss node 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.
agreed.
Co-authored-by: Jordan Harband <[email protected]>
Co-authored-by: Jordan Harband <[email protected]>
Co-authored-by: Jordan Harband <[email protected]>
Co-authored-by: Jordan Harband <[email protected]>
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.
@ghinks
LGTM, I think we should promote this guide and then I think it's good to merge!
@thescientist13 moved from drafts to docs as requested in the meeting |
docs/testing-guidelines.md
Outdated
Testing is even more important when new maintainers take over a package. Sometimes when we work on a codebase for a long time we forget to articulate all the cognitive load to which we have become accustomed. Good test coverage can alleviate this burden. | ||
|
||
### Updates | ||
Node.js has a [strict release pipeline](https://nodejs.org/en/about/releases/) focused on continuous improvement and update. In order to guarantee to your users that the module you made works correctly with the newer version of Node.js, it is a good practice to run your tests across multiple Node.js versions. |
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.
focused on continuous improvement and update
this seems like it's slightly incorrect English.
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.
In order to guarantee to your users that the module you made works correctly with the newer version of Node.js
how this is presented, "working correctly with the newer version of Node.js" is a value that's assumed but I don't think it's one that can in fact reasonably be assumed. From the project perspective yes we want things to work but we've not substantiated here why a maintainer would care.
Also, the phrasing is slightly confusing again.
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.
it is a good practice to run your tests across multiple Node.js versions.
I'm confused by this. The previous statement was future looking but how this is approached it's historical or at the very least in the present. Maybe this is just a prose issue, but the sentiment doesn't seem to match the previous section.
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.
After re-reading this after a break of a few days I agree with you @bnb I think some changes are required here. The first sentence about node's strict release schedule should actually be removed and some re-phrasing after wards will be required.
docs/testing-guidelines.md
Outdated
* LTS (long time support) | ||
* Current |
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 someone find out what these are? We should provide guidance here.
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.
agreed, there should be a link here.
For browser-based modules and modules that are designed to work equally both client and server side it is essential to test on various | ||
versions of your target browser and to publish which environments are supported. |
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.
Publish where?
docs/testing-guidelines.md
Outdated
* **unit test**: test your code | ||
* **integration test**: test your code with other applications dependencies | ||
* **acceptance test**: test your application sticks in performance, heavy load, etc.. |
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.
Capitalize bullets and don't use etc..
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.
Also given that you have headings under this further describing what's outlined here, you should probably make the bold parts also be relative links.
docs/testing-guidelines.md
Outdated
#### Integration Testing | ||
Integration testing in general requires that the code under test be in a package. | ||
|
||
For many packages integration testing requires that the built package be run via a testing tool upon several environments. The / |
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.
For many packages integration testing requires that the built package be run via a testing tool upon several environments. The / | |
For many packages, integration testing requires that the built package be run via a testing tool upon several environments. The `/` |
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.
not sure if this / is intentional or not?
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.
typo, not sure how the slash got there. Will remove.
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.
@bnb I think that we have satisfied your questions, could we have another review.
|
||
For many packages integration testing requires that the built package be run via a testing tool upon several environments. The / | ||
field of continuous integration and deployment (CI/CD) is complex. The package being built shall be run through | ||
a CI/CD pipeline. Several integrations are available for GitHub based repositories. (There are also alternatives to 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.
Several integrations are available for GitHub based repositories. (There are also alternatives to GitHub.)
we should try to substantiate this beyond just saying it exists.
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.
Agreed. Do we want more alternatives for Code like GitLabs or both code and CI/CD ?
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.
IMO both code and CI/CD.
Co-authored-by: Tierney Cyren <[email protected]>
Co-authored-by: Tierney Cyren <[email protected]>
Co-authored-by: Tierney Cyren <[email protected]>
LTS current references lines 16 Capitalize, bold and link lines 27-28 CI/CD pipeline reference 45, we will link once we do the CI/CD document. That I am sure will be subject to much debate.
address stray slash character.
addressing comment about node's strict release schedule by removing it as it is not pertinent to the maintainer.
I have made a number of changes to address comments and am asking for a further review. I am acknowledging that in a number of places we do need to link to our CI/CD document. But this is a chicken and egg relationship and both are required. It is my intent to come back here to make changes once we complete the CI/CD document. |
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.
@ghinks
Great work so far and thanks for moving out of drafts/ folder. 👍
I think in this case now we can also remove the (draft) from this in the Table of Contents as well
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.
Approving to get this moving, assuming followups to be done together with the ci/cd doc.
Co-authored-by: Rodion Abdurakhimov <[email protected]>
Lower the wording from guarantee to **indication** that a module is intended to work with newer versions.
change readme - remove draft
@ghinks |
I got it. |
I think this almost good to go now? Any final / outstanding feedback? @bnb do the latest changes look good to you? |
Discussed in the Package Maintenance meeting on the 8/25/2020 and there was consensus that we should land since there had not be a response from the originator's last objection and we believe the objection had been addressed. |
Apologies for the delay. Glad to see it landed ❤️ |
Update, fix and add to the current draft of the testing guidelines.
As part of issue 373 here are my updates to the testing guidelines.
It is essential we have some guidelines, although I believe that a whole thesis could be written on this one topic.