Italian Translation Report: Node.js [Part 30 - 1197 words]

Aug 20th, 2018
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
  1. How to write a test for the Node.js project
  2. What is a test?
  3. Most tests in Node.js core are JavaScript programs that exercise a functionality provided by Node.js and check that it behaves as expected.
  4. Tests should exit with code on success.
  5. A test will fail if:
  6. It exits by setting to a non-zero number.
  7. This is usually done by having an assertion throw an uncaught Error.
  8. Occasionally, using may be appropriate.
  9. It never exits.
  10. In this case, the test runner will terminate the test because it sets a maximum time limit.
  11. Add tests when:
  12. Adding new functionality.
  13. Fixing regressions and bugs.
  14. Expanding test coverage.
  15. Test directory structure
  16. See directory structure overview for outline of existing test & locations.
  17. When deciding on whether to expand an existing test file or create a new one, consider going through the files related to the subsystem.
  18. For example, look for when writing a test for.
  19. Test structure
  20. Let's analyze this basic test from the Node.js test suite:
  21. This test ensures that the can handle UTF-8 characters in the http header.
  22. Lines 1-3
  23. The first line enables strict mode.
  24. All tests should be in strict mode unless the nature of the test requires that the test run without it.
  25. The second line loads the module.
  26. The is a helper module that provides useful tools for the tests.
  27. Some common functionality has been extracted into submodules, which are required separately like the fixtures module here.
  28. Even if a test uses no functions or other properties exported by, the test should still include the module before any other modules
  29. This is because the module includes code that will cause a test to fail if the test leaks variables into the global space.
  30. In situations where a test uses no functions or other properties exported by, include it without assigning it to an identifier:
  31. A test should start with a comment containing a brief description of what it is designed to test.
  32. The test checks functionality in the module.
  33. Most tests use the module to confirm expectations of the test.
  34. The require statements are sorted in order (digits, upper case, lower case).
  35. This is the body of the test.
  36. This test is simple, it just tests that an HTTP server accepts characters in the headers of an incoming request.
  37. Interesting things to notice:
  38. If the test doesn't depend on a specific port number, then always use 0 instead of an arbitrary value, as it allows tests to run in parallel safely, as the operating system will assign a random port.
  39. If the test requires a specific port, for example if the test checks that assigning a specific port works as expected, then it is ok to assign a specific port number.
  40. The use of to check that some callbacks/listeners are called.
  41. The HTTP server closes once all the checks have run.
  42. This way, the test can exit gracefully.
  43. Remember that for a test to succeed, it must exit with a status code of 0.
  44. General recommendations
  45. Avoid timers unless the test is specifically testing timers.
  46. There are multiple reasons for this.
  47. Mainly, they are a source of flakiness.
  48. For a thorough explanation go here
  49. In the event a test needs a timer, consider using the method.
  50. It allows setting specific timeouts depending on the platform:
  51. will create a 4-second timeout on most platforms but a longer timeout on slower platforms.
  52. Make use of the helpers from the module as much as possible.
  53. Please refer to the common file documentation for the full details of the helpers.
  54. One interesting case is
  55. The use of may avoid the use of extra variables and the corresponding assertions.
  56. Let's explain this with a real test from the test suite.
  57. This test could be greatly simplified by using like this:
  58. The common provides a simple countdown mechanism for tests that require a particular action to be taken after a given number of completed tasks (for instance, shutting down an HTTP server after a specific number of requests).
  59. The countdown callback will be invoked now.
  60. Some tests will require running Node.js with specific command line flags set.
  61. To accomplish this, add a comment in the preamble of the test followed by the flags.
  62. For example, to allow a test to require some of the modules, add the flag.
  63. A test that would require could start like this:
  64. When writing assertions, prefer the strict versions:
  65. Instead of something like
  66. For performance considerations, we only use a selected subset of features in JavaScript code in the directory.
  67. However, when writing tests, for the ease of backporting, it is encouraged to use those features that can be used directly without a flag in all maintained branches
  68. lists available features in each release, such as:
  69. and over
  70. Template literals over string concatenation
  71. Arrow functions when appropriate
  72. Naming Test Files
  73. Test files are named using kebab casing.
  74. The first component of the name is
  75. The second is the module or subsystem being tested.
  76. The third is usually the method or event name being tested.
  77. Subsequent components of the name add more information about what is being tested.
  78. For example, a test for the event on the object might be named
  79. If the test specifically checked that arrow functions worked correctly with the event, then it might be named
  80. Imported Tests
  81. Web Platform Tests
  82. Some of the tests for the WHATWG URL implementation (named) are imported from the Web Platform Tests Project
  83. These imported tests will be wrapped like this:
  84. The following tests are copied from WPT.
  85. Modifications to them should be upstreamed first.
  86. To improve tests that have been imported this way, please send a PR to the upstream project first.
  87. When the proposed change is merged in the upstream project, send another PR here to update Node.js accordingly.
  88. Be sure to update the hash in the URL following
  89. C++ code can be tested using
  90. Most features in Node.js can be tested using the methods described previously in this document.
  91. But there are cases where these might not be enough, for example writing code for Node.js that will only be called when Node.js is embedded.
  92. Adding a new test
  93. The unit test should be placed in and be named with the prefix followed by the name of unit being tested.
  94. For example, the code below would be placed in
  95. Next add the test to the in the target in node.gyp:
  96. Note that the only sources that should be included in the target are actual test or helper source files.
  97. There might be a need to include specific object files that are compiled by the target and this can be done by adding them to the section in the target.
  98. The test can be executed by running the target:
  99. Node.js test fixture
  100. There is a named which can be included by unit tests.
  101. The fixture takes care of setting up the Node.js environment and tearing it down after the tests have finished.
  102. It also contains a helper to create arguments to be passed into Node.js.
  103. It will depend on what is being tested if this is required or not.
  104. To generate a test coverage report, see the Test Coverage section of the Pull Requests guide.
RAW Paste Data

Adblocker detected! Please consider disabling it...

We've detected AdBlock Plus or some other adblocking software preventing from fully loading.

We don't have any obnoxious sound, or popup ads, we actively block these annoying types of ads!

Please add to your ad blocker whitelist or disable your adblocking software.