Merge pull request #3577 from pablo-maff/part-4-node-test-spanish

Part 4 node test spanish

Author: mluukkai

src/content/3/es/part3a.md

@@ -982,7 +982,7 @@ app.use(requestLogger)
 
 Recuerda, las funciones middleware se llaman en el orden en el que son encontradas por el motor de JavaScript. Ten en cuenta que _json-parser_ se encuentra definido antes que _requestLogger_, porque de lo contrario, ¡<i>request.body</i> no se inicializará cuando se ejecute el logger!
 
-Las funciones de middleware deben utilizarse antes que las rutas cuando queremos que sean ejecutadas por los controladores de eventos de ruta. A veces, queremos usar funciones de middleware después que las rutas. Hacemos esto cuando las funciones de middleware solo son llamadas si ninguna ruta maneja la solicitud HTTP.
+Las funciones de middleware deben utilizarse antes que las rutas cuando queremos que sean ejecutadas por los controladores de eventos de ruta. A veces, queremos usar funciones de middleware después que las rutas. Hacemos esto cuando las funciones de middleware solo son llamadas si ningún controlador de ruta se encarga de la solicitud HTTP.
 
 Agreguemos el siguiente middleware después de nuestras rutas, que se usa para capturar solicitudes realizadas a rutas inexistentes. Para estas solicitudes, el middleware devolverá un mensaje de error en formato JSON.
 

src/content/4/en/part4.md

@@ -9,6 +9,6 @@ lang: en
 In this part, we will continue our work on the backend. Our first major theme will be writing unit and integration tests for the backend. After we have covered testing, we will take a look at implementing user authentication and authorization.
 
 <i>Part updated 13th Feb 2024</i>
-- <i>Jest replaced with Node embedded testrunner</i>
+- <i>Jest replaced with Node embedded test runner</i>
 
 </div>

src/content/4/en/part4a.md

@@ -11,7 +11,7 @@ Let's continue our work on the backend of the notes application we started in [p
 
 ### Project structure
 
-**Note** this course material was written with version v20.11.0 of Node.js. Please make sure that your version of Node is at least as new as the version used in the material (you can check the version by running node -v in the command line).
+**Note**: this course material was written with version v20.11.0 of Node.js. Please make sure that your version of Node is at least as new as the version used in the material (you can check the version by running _node -v_ in the command line).
 
 Before we move into the topic of testing, we will modify the structure of our project to adhere to Node.js best practices.
 
@@ -407,7 +407,7 @@ The nature of VS Code bleeding into how you write your code is probably not idea
 
 ### Exercises 4.1.-4.2.
 
-**Note** this course material was written with version v20.11.0 of Node.js. Please make sure that your version of Node is at least as new as the version used in the material (you can check the version by running node -v in the command line).
+**Note**: this course material was written with version v20.11.0 of Node.js. Please make sure that your version of Node is at least as new as the version used in the material (you can check the version by running _node -v_ in the command line).
 
 In the exercises for this part, we will be building a <i>blog list application</i>, that allows users to save information about interesting blogs they have stumbled across on the internet. For each listed blog we will save the author, title, URL, and amount of upvotes from users of the application.
 
@@ -569,7 +569,7 @@ In the next row, the test file imports the function to be tested and assigns it
 const reverse = require('../utils/for_testing').reverse
 ```
 
-Individual test cases are defined with the _test_ function. The first parameter of the function is the test description as a string. The second parameter is a <i>function</i>, that defines the functionality for the test case. The functionality for the second test case looks like this:
+Individual test cases are defined with the _test_ function. The first argument of the function is the test description as a string. The second argument is a <i>function</i>, that defines the functionality for the test case. The functionality for the second test case looks like this:
 
 ```js
 () => {
@@ -601,7 +601,7 @@ Running this test results in the following error message:
 
 ![terminal output shows failure from npm test](../../images/4/2new.png)
 
-Let output from the npm test with _average_ function, into a new file <i>tests/average.test.js</i>.
+Let's put the tests for the _average_ function, into a new file called <i>tests/average.test.js</i>.
 
 ```js
 const { test, describe } = require('node:test')
@@ -673,7 +673,7 @@ test('of empty array is zero', () => {
 
 ### Exercises 4.3.-4.7.
 
-Let's create a collection of helper functions that are best suited for working with the described sections of the blog list. Create the functions into a file called <i>utils/list_helper.js</i>. Write your tests into an appropriately named test file under the <i>tests</i> directory.
+Let's create a collection of helper functions that are best suited for working with the describe sections of the blog list. Create the functions into a file called <i>utils/list_helper.js</i>. Write your tests into an appropriately named test file under the <i>tests</i> directory.
 
 #### 4.3: Helper Functions and Unit Tests, step 1
 

src/content/4/en/part4b.md

@@ -231,7 +231,7 @@ test('the first note is about HTTP methods', async () => {
   const response = await api.get('/api/notes')
 
   const contents = response.body.map(e => e.content)
-  // is the parameter truthy
+  // is the argument truthy
   assert(contents.includes('HTML is easy'))
 })
 ```
@@ -275,7 +275,7 @@ module.exports = {
 
 Testing appears to be easy and our tests are currently passing. However, our tests are bad as they are dependent on the state of the database, that now  happens to have two notes. To make them more robust, we have to reset the database and generate the needed test data in a controlled manner before we run the tests.
 
-Our tests are already using the[after](https://nodejs.org/api/test.html#afterfn-options) function of to close the connection to the database after the tests are finished executing. The library Node:test offers many other functions that can be used for executing operations once before any test is run or every time before a test is run.
+Our tests are already using the [after](https://nodejs.org/api/test.html#afterfn-options) function of to close the connection to the database after the tests are finished executing. The library node:test offers many other functions that can be used for executing operations once before any test is run or every time before a test is run.
 
 Let's initialize the database <i>before every test</i> with the [beforeEach](https://nodejs.org/api/test.html#beforeeachfn-options) function:
 
@@ -337,7 +337,7 @@ test('the first note is about HTTP methods', async () => {
 
 The _npm test_ command executes all of the tests for the application. When we are writing tests, it is usually wise to only execute one or two tests. 
 
-There are a few different ways of accomplishing this, one of which is the [only](https://nodejs.org/api/test.html#testonlyname-options-fn) method. With the method we can define in the code what tests should be executed:
+There are a few different ways of accomplishing this, one of which is the [only](https://nodejs.org/api/test.html#testonlyname-options-fn) method. With this method we can define in the code what tests should be executed:
 
 ```js
 test.only('notes are returned as json', async () => {
@@ -354,31 +354,31 @@ test.only('there are two notes', async () => {
 })
 ```
 
-When tests are run with option _--test-only_, that is, with the command
+When tests are run with option _--test-only_, that is, with the command:
 
 ```
 npm test -- --test-only
 ```
 
 only the _only_ marked tests are executed.
 
-The danger of the _only_ is that one forgets to remove those from the code.
+The danger of _only_ is that one forgets to remove those from the code.
 
-Another option is to specify the tests that need to be run as parameters of the <i>npm test</i> command.
+Another option is to specify the tests that need to be run as arguments of the <i>npm test</i> command.
 
 The following command only runs the tests found in the <i>tests/note_api.test.js</i> file:
 
 ```js
 npm test -- tests/note_api.test.js
 ```
 
-The [--tests-by-name-pattern](https://nodejs.org/api/test.html#filtering-tests-by-name)  option can be used for running tests with a specific name:
+The [--tests-by-name-pattern](https://nodejs.org/api/test.html#filtering-tests-by-name) option can be used for running tests with a specific name:
 
 ```js
 npm test -- --test-name-pattern="the first note is about HTTP methods"
 ```
 
-The provided parameter can refer to the name of the test or the describe block. The parameter can also contain just a part of the name. The following command will run all of the tests that contain <i>notes</i> in their name:
+The provided argument can refer to the name of the test or the describe block. It can also contain just a part of the name. The following command will run all of the tests that contain <i>notes</i> in their name:
 
 ```js
 npm run test -- --test-name-pattern="notes"
@@ -960,7 +960,7 @@ beforeEach(async () => {
 
 The solution is quite advanced despite its compact appearance. The _noteObjects_ variable is assigned to an array of Mongoose objects that are created with the _Note_ constructor for each of the notes in the _helper.initialNotes_ array. The next line of code creates a new array that <i>consists of promises</i>, that are created by calling the _save_ method of each item in the _noteObjects_ array. In other words, it is an array of promises for saving each of the items to the database.
 
-The [Promise.all](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/all) method can be used for transforming an array of promises into a single promise, that will be <i>fulfilled</i> once every promise in the array passed to it as a parameter is resolved. The last line of code <em>await Promise.all(promiseArray)</em> waits until every promise for saving a note is finished, meaning that the database has been initialized.
+The [Promise.all](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/all) method can be used for transforming an array of promises into a single promise, that will be <i>fulfilled</i> once every promise in the array passed to it as an argument is resolved. The last line of code <em>await Promise.all(promiseArray)</em> waits until every promise for saving a note is finished, meaning that the database has been initialized.
 
 > The returned values of each promise in the array can still be accessed when using the Promise.all method. If we wait for the promises to be resolved with the _await_ syntax <em>const results = await Promise.all(promiseArray)</em>, the operation will return an array that contains the resolved values for each promise in the _promiseArray_, and they appear in the same order as the promises in the array.
 
@@ -1183,7 +1183,7 @@ after(async () => {
 
 The test output in the console is grouped according to the <i>describe</i> blocks:
 
-![jest output showing grouped describe blocks](../../images/4/7new.png)
+![node:test output showing grouped describe blocks](../../images/4/7new.png)
 
 There is still room for improvement, but it is time to move forward.
 

src/content/4/en/part4c.md

@@ -491,13 +491,13 @@ usersRouter.get('/', async (request, response) => {
 })
 ```
 
-The [populate](http://mongoosejs.com/docs/populate.html) method is chained after the <i>find</i> method making the initial query. The parameter given to the populate method defines that the <i>ids</i> referencing <i>note</i> objects in the <i>notes</i> field of the <i>user</i> document will be replaced by the referenced <i>note</i> documents.
+The [populate](http://mongoosejs.com/docs/populate.html) method is chained after the <i>find</i> method making the initial query. The argument given to the populate method defines that the <i>ids</i> referencing <i>note</i> objects in the <i>notes</i> field of the <i>user</i> document will be replaced by the referenced <i>note</i> documents.
 
 The result is almost exactly what we wanted:
 
 ![JSON data showing populated notes and users data with repetition](../../images/4/13new.png)
 
-We can use the populate parameter for choosing the fields we want to include from the documents. In addition to the field <i>id</i> we are now only interested in <i>content</i> and <i>important</i>.
+We can use the populate method for choosing the fields we want to include from the documents. In addition to the field <i>id</i> we are now only interested in <i>content</i> and <i>important</i>.
 
 The selection of fields is done with the Mongo [syntax](https://www.mongodb.com/docs/manual/tutorial/project-fields-from-query-results/#return-the-specified-fields-and-the-_id-field-only):
 

src/content/4/en/part4d.md

@@ -393,7 +393,7 @@ The operation must respond with a suitable status code and some kind of an error
 
 Also, **implement tests** that ensure invalid users are not created and that an invalid add user operation returns a suitable status code and error message.
 
-**NB** if you decide to define tests on multiple files, you should note that by default each test file is executed in its own process (see _Test execution model_ in the [documentation](https://nodejs.org/api/test.html)). The consequence of this is that different test files are executed at the same time. Since the tests share the same database, simultaneous execution may cause problems. Problems are avoided by executing the tests with the option _--test-concurrency=1_, i.e. defining them to be executed sequentially.
+**NB** if you decide to define tests on multiple files, you should note that by default each test file is executed in its own process (see _Test execution model_ in the [documentation](https://nodejs.org/api/test.html#test-runner-execution-model)). The consequence of this is that different test files are executed at the same time. Since the tests share the same database, simultaneous execution may cause problems, which can be avoided by executing the tests with the option _--test-concurrency=1_, i.e. defining them to be executed sequentially.
 
 #### 4.17: Blog List Expansion, step 5
 
@@ -520,7 +520,7 @@ app.use('/api/users', usersRouter)
 app.use('/api/login', loginRouter)
 ```
 
-As can be seen, this happens by chaining multiple middlewares as the parameter of function <i>use</i>. It would also be possible to register a middleware only for a specific operation:
+As can be seen, this happens by chaining multiple middlewares as the arguments of the function <i>use</i>. It would also be possible to register a middleware only for a specific operation:
 
 ```js
 const middleware = require('../utils/middleware');

src/content/4/es/part4.md

@@ -8,7 +8,7 @@ lang: es
 
 En esta parte, continuaremos nuestro trabajo en el backend. Nuestro primer tema principal será escribir pruebas de unidad e integración para el backend. Una vez que hayamos cubierto las pruebas, analizaremos la implementación de la autenticación y autorización de usuario.
 
-<i>Parte actualizada el 22 de enero de 2023</i>
-- <i>No hay cambios importantes</i>
+<i>Parte actualizada el 13 de Febrero de 2024</i>
+- <i>Jest reemplazado con el test runner integrado de Node</i>
 
 </div>