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

Test doctool #6031

Closed
wants to merge 1 commit into from
Closed

Test doctool #6031

wants to merge 1 commit into from

Conversation

iankronquist
Copy link
Contributor

Pull Request check-list

  • Does make -j8 test (UNIX) or vcbuild test nosign (Windows) pass with
    this change (including linting)?
  • Is the commit message formatted according to CONTRIBUTING.md?
  • If this change fixes a bug (or a performance problem), is a regression
    test (or a benchmark) included?
  • Is a documentation update included (if this change modifies
    existing APIs, or introduces new ones)? (N/A)

Affected core subsystem(s)

tools/doc

Description of change

Add tests for tools/doc. Fixes #5955. Includes tests for the functions toHTML (in html.js) and doJSON (in json.js). Also includes a regression test for #5873. Also introduces a new make target to run the tests.

I expect to be asked to squash these commits.

@iankronquist iankronquist mentioned this pull request Apr 4, 2016
@MylesBorins
Copy link
Contributor

Should these tests be including in the tests/ dir rather than docs/? /cc @nodejs/documentation @nodejs/testing

Are we going to want to run these in ci? /cc @nodejs/build

@iankronquist
Copy link
Contributor Author

@thealphanerd I put them there because tools/doc is its own independent package which could be distributed separately from node code.
These new tests run if you do the make test target, so presumably they would run during CI.


if (err) throw err;
assert(output.source == 'foo');
assert(JSON.stringify(output) == JSON.stringify(item.json));
Copy link
Member

Choose a reason for hiding this comment

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

Any reason not to use assert.equal(output.source, 'foo'), assert.deepStrictEqual(output, item.json)?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Because I didn't know those existed. Let me fix that.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fixed.

@iankronquist iankronquist force-pushed the test-doctool branch 2 times, most recently from 931ff1d to f240d02 Compare April 4, 2016 01:02
@jasnell jasnell added the test Issues and PRs related to the tests. label Apr 4, 2016
@stevemao
Copy link
Contributor

stevemao commented Apr 4, 2016

Are we going to want to run these in ci?

Should definitely run in ci.

Should these tests be including in the tests/ dir rather than docs/?

I think these tests should be in docs/

@Trott
Copy link
Member

Trott commented Apr 4, 2016

This PR adds test-doc to Makefile but it also needs to be added to vcbuild.bat for Windows.

@Trott
Copy link
Member

Trott commented Apr 4, 2016

Should these tests be including in the tests/ dir rather than docs/?

Yes. Tests should go in the test directory.

As far as where in the test directory: They could go in a new directory like test/doc but oddball directories like that tend to be test graveyards (whassup test/debugger and test/pummel?). It would probably be just fine in test/parallel. Then it would run automatically in CI and if we ever introduce a change that breaks the doc tools, these tests might actually catch it before the change lands.

@Trott
Copy link
Member

Trott commented Apr 4, 2016

I put them there because tools/doc is its own independent package which could be distributed separately from node code.

I see the logic there and wouldn't stand in the way if others agreed. I look at it this way, though: All tests for the project are in the test directory and I really don't want to have to remember that there's this other oddball set of tests that is somewhere else. That just seems like cognitive overhead we can avoid.

@Trott
Copy link
Member

Trott commented Apr 4, 2016

These new tests run if you do the make test target, so presumably they would run during CI.

CI runs the make test-ci job, not make test. So you need to add it to that job. Also, it needs to be added to test-ci in vcbuild.bat to run on Windows.

@Trott
Copy link
Member

Trott commented Apr 4, 2016

Another argument for adding these to the project-wide test directory: Then they get linted with the lint rules for our tests rather than the lint rules for the doc directory. These tests don't load the common module the way all our tests are required to (because that module is what we use to detect leaked globals).

EDIT: Putting them in test/parallel also means that we can get TAP output from test.py and we can run stress tests in CI if we ever have a flaky test for the doctool.

@Trott
Copy link
Member

Trott commented Apr 4, 2016

Last comment for now, I promise, sorry for the storm of notifications: YES YES YES! +100 to having some tests for the doc tools.

@Trott Trott added the doc Issues and PRs related to the documentations. label Apr 4, 2016
@iankronquist
Copy link
Contributor Author

@Trott I don't have access to a windows system. I could put some code in vcbuild.bat and hope that it works if you'd like.

@Trott
Copy link
Member

Trott commented Apr 4, 2016

I don't have access to a windows system. I could put some code in vcbuild.bat and hope that it works if you'd like.

One more benefit to putting these tests in test/parallel: You won't need any changes at all to Makefile or vcbuild.bat. Everything will just work. The tests will run in CI on all platforms.

@iankronquist
Copy link
Contributor Author

@Trott here's a version with the tests living under test/
iankronquist/io.js@test-doctool...iankronquist:test-doctool-tests

@Trott
Copy link
Member

Trott commented Apr 4, 2016

here's a version with the tests living under test/

💯 😍 👍

@Trott
Copy link
Member

Trott commented Apr 4, 2016

@thealphanerd @jasnell I'm adding the lts-watch-v4.x label to this PR. Apologies in advance if that's misguided. Seems like it should be brought into LTS if it lands cleanly.

@@ -0,0 +1,50 @@
'use strict';

var assert = require('assert');
Copy link
Member

Choose a reason for hiding this comment

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

Nit (which means you can ignore this comment if you want to): The project has been favoring const over var for module imports like this.

@Knighton910
Copy link

👍

@eljefedelrodeodeljefe
Copy link
Contributor

I think that is pretty much what @silverwind intended. Good stuff.

});
}

test_toHTML();
Copy link
Contributor

Choose a reason for hiding this comment

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

Can we not wrap this in a function. With this being the only thing in the file, it's a bit redundant.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fixed.

@evanlucas
Copy link
Contributor

Thanks for the contribution! I'm with @Trott. Please make every variable const that can be. I think this is great though. I would really like to see us add support for verifying there are no broken link references, but that is something that can happen after the initial version gets merged.

I would prefer that we keep these in the test/ directory.

// Test data is a list of objects with two properties.
// The file property is the file path.
// The html property is some html which will be generated by the doctool.
// This html will be stripped of all whitespace.
Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe change the comment to state that it will be stripped of all unnecessary whitespace?

Edit: disregard. I just realized why you were doing that. Maybe update the comment to be more clear?

@iankronquist
Copy link
Contributor Author

Looks like CI passed.

@silverwind
Copy link
Contributor

silverwind commented Apr 21, 2016

@iankronquist
Copy link
Contributor Author

@silverwind Is there anyone else I need to get to take a look at this?

fs.readFile(item.file, 'utf8', common.mustCall(function(err, input) {
assert.ifError(err);
html(input, 'foo', 'doc/template.html',
common.mustCall(function(err, output) {
Copy link
Member

Choose a reason for hiding this comment

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

shouldn't common.mustCall... be aligned with input?

@silverwind
Copy link
Contributor

@iankronquist after you've handled above comments, I suggest you squash the commits into a single one and add a nice summary of the changes in the commit message.

Addresses nodejs#5955 on GitHub.
* Test the toHTML function in html.js. Check that given valid markdown it
produces the expected html. One test case will prevent regressions of
big nodejs#5873.
* Check that when given valid markdown toJSON produces valid JSON with the
expected schema.
* Add doctool to the list of built in tests so it runs in CI.
@iankronquist
Copy link
Contributor Author

@silverwind fixed & squashed.

silverwind pushed a commit that referenced this pull request Apr 28, 2016
* Test the toHTML function in html.js. Check that given valid markdown
  it produces the expected html. One test case will prevent regressions
  of #5873.
* Check that when given valid markdown toJSON produces valid JSON with
  the expected schema.
* Add doctool to the list of built in tests so it runs in CI.

PR-URL: #6031
Fixes: #5955
Reviewed-By: Roman Reiss <[email protected]>
Reviewed-By: Rich Trott <[email protected]>
@silverwind
Copy link
Contributor

Thanks! Landed in 2e845f8 with some minor corrections to the commit message. Nice work!

@silverwind silverwind closed this Apr 28, 2016
@eljefedelrodeodeljefe
Copy link
Contributor

Yes, really nice. Thx for the effort. Time to try it myself :) Awesome guys.

@iankronquist
Copy link
Contributor Author

@silverwind excellent, thanks!

Fishrock123 pushed a commit that referenced this pull request May 4, 2016
* Test the toHTML function in html.js. Check that given valid markdown
  it produces the expected html. One test case will prevent regressions
  of #5873.
* Check that when given valid markdown toJSON produces valid JSON with
  the expected schema.
* Add doctool to the list of built in tests so it runs in CI.

PR-URL: #6031
Fixes: #5955
Reviewed-By: Roman Reiss <[email protected]>
Reviewed-By: Rich Trott <[email protected]>
@MylesBorins
Copy link
Contributor

if someone would like to see this landed it will need to be manually backported

@iankronquist
Copy link
Contributor Author

@thealphanerd didn't this land in 2e845f8? Do you mean landed in the next release?

@MylesBorins
Copy link
Contributor

Sorry for not being exact... I was referring to lts

MylesBorins pushed a commit that referenced this pull request Jun 1, 2016
* Test the toHTML function in html.js. Check that given valid markdown
  it produces the expected html. One test case will prevent regressions
  of #5873.
* Check that when given valid markdown toJSON produces valid JSON with
  the expected schema.
* Add doctool to the list of built in tests so it runs in CI.

PR-URL: #6031
Fixes: #5955
Reviewed-By: Roman Reiss <[email protected]>
Reviewed-By: Rich Trott <[email protected]>
MylesBorins pushed a commit that referenced this pull request Jun 23, 2016
* Test the toHTML function in html.js. Check that given valid markdown
  it produces the expected html. One test case will prevent regressions
  of #5873.
* Check that when given valid markdown toJSON produces valid JSON with
  the expected schema.
* Add doctool to the list of built in tests so it runs in CI.

PR-URL: #6031
Fixes: #5955
Reviewed-By: Roman Reiss <[email protected]>
Reviewed-By: Rich Trott <[email protected]>
MylesBorins pushed a commit that referenced this pull request Jun 24, 2016
* Test the toHTML function in html.js. Check that given valid markdown
  it produces the expected html. One test case will prevent regressions
  of #5873.
* Check that when given valid markdown toJSON produces valid JSON with
  the expected schema.
* Add doctool to the list of built in tests so it runs in CI.

PR-URL: #6031
Fixes: #5955
Reviewed-By: Roman Reiss <[email protected]>
Reviewed-By: Rich Trott <[email protected]>
@MylesBorins MylesBorins mentioned this pull request Jun 24, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
doc Issues and PRs related to the documentations. test Issues and PRs related to the tests.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Testing the doctool