From c82f0f10fc894215c69afc6ff09fca5899180497 Mon Sep 17 00:00:00 2001 From: alexseik Date: Fri, 10 Apr 2020 14:13:40 +0200 Subject: [PATCH 1/3] Update 05-testing-mocha article.md and task.md --- .../3-pow-test-wrong/solution.md | 32 +- .../05-testing-mocha/3-pow-test-wrong/task.md | 8 +- .../05-testing-mocha/article.md | 299 +++++++++--------- .../beforeafter.view/index.html | 17 +- .../05-testing-mocha/beforeafter.view/test.js | 8 +- .../05-testing-mocha/index.html | 18 +- .../05-testing-mocha/pow-1.view/index.html | 19 +- .../05-testing-mocha/pow-1.view/test.js | 2 +- .../05-testing-mocha/pow-2.view/index.html | 20 +- .../05-testing-mocha/pow-2.view/test.js | 4 +- .../05-testing-mocha/pow-3.view/index.html | 17 +- .../05-testing-mocha/pow-3.view/test.js | 2 +- .../05-testing-mocha/pow-4.view/index.html | 17 +- .../05-testing-mocha/pow-4.view/test.js | 4 +- .../05-testing-mocha/pow-full.view/index.html | 17 +- .../05-testing-mocha/pow-full.view/test.js | 8 +- .../05-testing-mocha/pow-min.view/index.html | 19 +- .../05-testing-mocha/pow-min.view/test.js | 2 +- .../05-testing-mocha/pow-nan.view/index.html | 17 +- .../05-testing-mocha/pow-nan.view/test.js | 8 +- 20 files changed, 263 insertions(+), 275 deletions(-) diff --git a/1-js/03-code-quality/05-testing-mocha/3-pow-test-wrong/solution.md b/1-js/03-code-quality/05-testing-mocha/3-pow-test-wrong/solution.md index 7b58f0bf1..6c0ecf179 100644 --- a/1-js/03-code-quality/05-testing-mocha/3-pow-test-wrong/solution.md +++ b/1-js/03-code-quality/05-testing-mocha/3-pow-test-wrong/solution.md @@ -1,49 +1,47 @@ -The test demonstrates one of the temptations a developer meets when writing tests. +El test demuestra una tentación habitual del/a desarrollador/a al escribir tests. -What we have here is actually 3 tests, but layed out as a single function with 3 asserts. +Lo que tenemos aquí son en realidad 3 pruebas, pero presentadas como una sola función con 3 afirmaciones. -Sometimes it's easier to write this way, but if an error occurs, it's much less obvious what went wrong. +A veces es más fácil escribir de esta manera, pero si ocurre un error, es mucho menos obvio saber qué salió mal. -If an error happens inside a complex execution flow, then we'll have to figure out the data at that point. We'll actually have to *debug the test*. +Sería mucho mejor dividir la prueba en múltiples bloques 'it' con entradas y salidas claramente escritas. -It would be much better to break the test into multiple `it` blocks with clearly written inputs and outputs. - -Like this: +Como ésto: ```js -describe("Raises x to power n", function() { - it("5 in the power of 1 equals 5", function() { +describe("Eleva x a la potencia n", function() { + it("5 elevado a 1 es igual a 5", function() { assert.equal(pow(5, 1), 5); }); - it("5 in the power of 2 equals 25", function() { + it("5 elevado a 2 es igual a 25", function() { assert.equal(pow(5, 2), 25); }); - it("5 in the power of 3 equals 125", function() { + it("5 elevado a 3 es igual a 125", function() { assert.equal(pow(5, 3), 125); }); }); ``` -We replaced the single `it` with `describe` and a group of `it` blocks. Now if something fails we would see clearly what the data was. +Reemplazamos el único `it` por un `describe` y agrupamos los bloques `it` dentro. Ahora si algo sale mal, podemos ver claramente que dato fue. -Also we can isolate a single test and run it in standalone mode by writing `it.only` instead of `it`: +Además podemos aislar un único test y ejecutarlo individualmente escribiendo `it.only` en lugar de `it`: ```js describe("Raises x to power n", function() { - it("5 in the power of 1 equals 5", function() { + it("5 elevado a 1 es igual a 5", function() { assert.equal(pow(5, 1), 5); }); *!* - // Mocha will run only this block - it.only("5 in the power of 2 equals 25", function() { + // Mocha sólo ejecutará este bloque + it.only("5 elevado a 2 es igual a 25", function() { assert.equal(pow(5, 2), 25); }); */!* - it("5 in the power of 3 equals 125", function() { + it("5 elevado a 3 es igual a 125", function() { assert.equal(pow(5, 3), 125); }); }); diff --git a/1-js/03-code-quality/05-testing-mocha/3-pow-test-wrong/task.md b/1-js/03-code-quality/05-testing-mocha/3-pow-test-wrong/task.md index 66fece09a..23ba8d8ba 100644 --- a/1-js/03-code-quality/05-testing-mocha/3-pow-test-wrong/task.md +++ b/1-js/03-code-quality/05-testing-mocha/3-pow-test-wrong/task.md @@ -2,12 +2,12 @@ importance: 5 --- -# What's wrong in the test? +# ¿Qué esta mal en el test? -What's wrong in the test of `pow` below? +¿Qué es incorrecto en el test de `pow` de abajo? ```js -it("Raises x to the power n", function() { +it("Eleva x a la potencia n", function() { let x = 5; let result = x; @@ -21,4 +21,4 @@ it("Raises x to the power n", function() { }); ``` -P.S. Syntactically the test is correct and passes. +P.S. El test es sintácticamente correcto y pasa. diff --git a/1-js/03-code-quality/05-testing-mocha/article.md b/1-js/03-code-quality/05-testing-mocha/article.md index c7b164b15..e399bc989 100644 --- a/1-js/03-code-quality/05-testing-mocha/article.md +++ b/1-js/03-code-quality/05-testing-mocha/article.md @@ -1,147 +1,146 @@ -# Automated testing with mocha +# Test automatizados con mocha -Automated testing will be used in further tasks. +Los tests automáticos deben ser considerados como una tarea más. -It's actually a part of the "educational minimum" of a developer. +Debe ser parte del "conocimiento mínimo" de un/a desarrollador/a. -## Why we need tests? +## ¿Por qué necesitamos tests? -When we write a function, we can usually imagine what it should do: which parameters give which results. +Cuando escribimos una función, normalmente imaginamos qué debe hacer: Para ciertos parámetros, que resultado. -During development, we can check the function by running it and comparing the outcome with the expected one. For instance, we can do it in the console. +Durante el desarrollo, podemos comprobar la función ejecutándola y comparando el resultado con la salida esperada. Por ejemplo, podemos hacer eso en la consola. -If something is wrong -- then we fix the code, run again, check the result -- and so on till it works. +Si algo esta incorrecto -- entonces corregimos el código, ejecutamos de nuevo, comprobamos resultado -- y así sucesivamente hasta que funcione. -But such manual "re-runs" are imperfect. +Pero esa "re-ejecuciones" manuales son imperfectas. -**When testing a code by manual re-runs, it's easy to miss something.** +**Cuando testeamos un código re-ejecutándolo manualmente es fácil obviar algo.** -For instance, we're creating a function `f`. Wrote some code, testing: `f(1)` works, but `f(2)` doesn't work. We fix the code and now `f(2)` works. Looks complete? But we forgot to re-test `f(1)`. That may lead to an error. +Por ejemplo, si estamos creando una función `f`. Escribimos algo de código, testeamos: `f(1)` funciona, pero `f(2)` no funciona. Corregimos el código y ahora funciona `f(2)`. ¿Está completo? Hemos olvidado re-testear `f(1)`. Esto puede resultar error. -That's very typical. When we develop something, we keep a lot of possible use cases in mind. But it's hard to expect a programmer to check all of them manually after every change. So it becomes easy to fix one thing and break another one. +Todo esto es muy típico. Cuando desarrollamos algo, mantenemos muchos casos de uso posibles en la cabeza. Pero es complicado esperar que un/a programador/a compruebe todos después de cada cambio. Por lo que deviene fácil arreglar una cosa y romper otra. -**Automated testing means that tests are written separately, in addition to the code. They can be executed easily and check all the main use cases.** +**Los tests automatizados implican escribir los tests por separado, además del código. Pueden ser ejecutados fácilmente y comprueban todos los casos de uso principales.** -## Behavior Driven Development (BDD) +## Behavior Driven Development (BDD) -Let's use a technique named [Behavior Driven Development](http://en.wikipedia.org/wiki/Behavior-driven_development) or, in short, BDD. That approach is used among many projects. BDD is not just about testing. That's more. +Vamos a usar una técnica llamada [Desarrollo guiado por comportamiento](http://en.wikipedia.org/wiki/Behavior-driven_development) o por sus siglas en inglés, BDD. Es una aproximación utilizada en muchos proyectos. BDD no es solo hacer test. Es más. -**BDD is three things in one: tests AND documentation AND examples.** +**BDD son tres cosas en uno: tests, documentación y ejemplos.** -Enough words. Let's see the example. +Basta de palabras, veamos un ejemplo: -## Development of "pow": the spec +## Desarrollo de "potencia de un número (pow)": la especificación -Let's say we want to make a function `pow(x, n)` that raises `x` to an integer power `n`. We assume that `n≥0`. +Digamos que queremos hacer una función `pow(x, n)` que eleve `x` a la potencia de un entero `n`. Asumimos que `n≥0`. -That task is just an example: there's the `**` operator in JavaScript that can do that, but here we concentrate on the development flow that can be applied to more complex tasks as well. +Esta tarea es sólo un ejemplo: Hay un operador `**` en JavaScript que hace eso, pero queremos concentrarnos en el flujo de desarrollo que puede ser aplicado a tareas más complejas. -Before creating the code of `pow`, we can imagine what the function should do and describe it. - -Such description is called a *specification* or, in short, a spec, and looks like this: +Antes de crear el código de `pow`, podemos imaginar lo que hace la función y describirlo. +Esa descripción es llamada *especificación* o una spec y se asemeja a: ```js describe("pow", function() { - it("raises to n-th power", function() { + it("eleva a la n-ésima potencia", function() { assert.equal(pow(2, 3), 8); }); }); ``` -A spec has three main building blocks that you can see above: +Una spec tiene los tres bloques principales mostrados abajo: -`describe("title", function() { ... })` -: What functionality we're describing. Uses to group "workers" -- the `it` blocks. In our case we're describing the function `pow`. +`describe("titulo", function() { ... })` +: Qué funcionalidad estamos describiendo. Utilizado para agrupar los "trabajadores" -- los bloques `it`. En nuestro caso estamos describiendo la función `pow`. -`it("title", function() { ... })` -: In the title of `it` we *in a human-readable way* describe the particular use case, and the second argument is a function that tests it. +`it("titulo", function() { ... })` +: En el título de `it` introducimos una descripción entendible en forma humana del caso de uso. El segundo argumento es la función que testea eso. `assert.equal(value1, value2)` -: The code inside `it` block, if the implementation is correct, should execute without errors. +: El código dentro del bloque `it`, si la implementación es correcta, debe ejecutar sin errores. - Functions `assert.*` are used to check whether `pow` works as expected. Right here we're using one of them -- `assert.equal`, it compares arguments and yields an error if they are not equal. Here it checks that the result of `pow(2, 3)` equals `8`. + Las funciones `assert.*` son usadas para comprobar cuando `pow` funciona como esperamos. Justo aquí utilizamos una de ellas -- `assert.equal`, que compara argumentos y produce un error si los mismos no son iguales. Arriba se está comprobando que el resultado de `pow(2, 3)` es igual a `8`. - There are other types of comparisons and checks that we'll see further. + Hay otros tipos de comparaciones y comprobaciones que veremos más adelante. -## The development flow +## El flujo de desarrollo -The flow of development usually looks like this: +El flujo de desarrollo podría asemejarse a: -1. An initial spec is written, with tests for the most basic functionality. -2. An initial implementation is created. -3. To check whether it works, we run the testing framework [Mocha](http://mochajs.org/) (more details soon) that runs the spec. Errors are displayed. We make corrections until everything works. -4. Now we have a working initial implementation with tests. -5. We add more use cases to the spec, probably not yet supported by the implementations. Tests start to fail. -6. Go to 3, update the implementation till tests give no errors. -7. Repeat steps 3-6 till the functionality is ready. +1. Un spec inicial es escrito, con tests para la funcionalidad más básica. +2. Una implementación inicial es creada. +3. Para comprobar que funciona, ejecutamos el framework de test [Mocha](http://mochajs.org/) (detallado más adelante) que ejecuta el spec. Los errores son mostrados. Hacemos correcciones hasta que todo funciona. +4. Ahora tenemos una implementación inicial con tests. +5. Añadimos más casos de uso al spec, seguramente no soportados aún por la implementación. Los tests empiezan a fallar. +6. Ir a 3, actualizar la implementación hasta que los tests no den errores. +7. Repetir pasos 3-6 hasta que la funcionalidad este lista. -So, the development is *iterative*. We write the spec, implement it, make sure tests pass, then write more tests, make sure they work etc. At the end we have both a working implementation and tests for it. +De tal forma que el desarrollo es iterativo. Escribimos la especificación, la implementamos, aseguramos que los tests pasen y entonces escribimos más tests y volvemos a asegurar que pasen, etc. Al final tenemos una implementación funcionando con tests para ella. -In our case, the first step is complete: we have an initial spec for `pow`. So let's make an implementation. But before that let's make a "zero" run of the spec, just to see that tests are working (they will all fail). +En nuestro caso, el primer paso esta completo: tenemos una spec inicial para `pow`. Vamos a realizar la implementación. Pero antes de comenzar hemos de asegurarnos que los test se ejecutan (no hay errores de sintáxis ni de compilación pero van a fallar todos). -## The spec in action +## La spec en acción -Here in the tutorial we'll be using the following JavaScript libraries for tests: +En éste tutorial estamos usando las siguientes librerías JavaScript para los tests: -- [Mocha](http://mochajs.org/) -- the core framework: it provides common testing functions including `describe` and `it` and the main function that runs tests. -- [Chai](http://chaijs.com) -- the library with many assertions. It allows to use a lot of different assertions, for now we need only `assert.equal`. -- [Sinon](http://sinonjs.org/) -- a library to spy over functions, emulate built-in functions and more, we'll need it much later. +- [Mocha](http://mochajs.org/) -- el framework central: provee de funciones para test comunes como `describe` e `it` y la función principal que ejecuta los tests. +- [Chai](http://chaijs.com) -- una librería con muchas funciones de comprobación (assertions). Permite el uso de diferentes comprobaciones. De momento usaremos `assert.equal`. +- [Sinon](http://sinonjs.org/) -- una libraería para espiar funciones. Simula funciones incorparadas al lenguaje y mucho más. La necesitaremos a menudo más adelante. -These libraries are suitable for both in-browser and server-side testing. Here we'll consider the browser variant. +Estas librerías son adecuadas tanto para tests en el navegador como en el lado del servidor. Aquí nos enfocaremos en el lado del navegador. -The full HTML page with these frameworks and `pow` spec: +La página HTML con estos frameworks y la spec de `pow`: ```html src="index.html" ``` -The page can be divided into five parts: +La página puede ser dividida en cinco partes: -1. The `` -- add third-party libraries and styles for tests. -2. The ` - + - + - +
- + diff --git a/1-js/03-code-quality/05-testing-mocha/beforeafter.view/test.js b/1-js/03-code-quality/05-testing-mocha/beforeafter.view/test.js index cad51d3ee..e125807a8 100644 --- a/1-js/03-code-quality/05-testing-mocha/beforeafter.view/test.js +++ b/1-js/03-code-quality/05-testing-mocha/beforeafter.view/test.js @@ -1,10 +1,10 @@ describe("test", function() { - before(() => alert("Testing started – before all tests")); - after(() => alert("Testing finished – after all tests")); + before(() => alert("Inicio testing – antes de todos los tests")); + after(() => alert("Final testing – después de todos los tests")); - beforeEach(() => alert("Before a test – enter a test")); - afterEach(() => alert("After a test – exit a test")); + beforeEach(() => alert("Antes de un test – entramos al test")); + afterEach(() => alert("Después de un test – salimos del test")); it('test 1', () => alert(1)); it('test 2', () => alert(2)); diff --git a/1-js/03-code-quality/05-testing-mocha/index.html b/1-js/03-code-quality/05-testing-mocha/index.html index 28a2ea62b..823b95904 100644 --- a/1-js/03-code-quality/05-testing-mocha/index.html +++ b/1-js/03-code-quality/05-testing-mocha/index.html @@ -1,17 +1,17 @@ - + - + - + @@ -20,17 +20,17 @@ - + - +
- + diff --git a/1-js/03-code-quality/05-testing-mocha/pow-1.view/index.html b/1-js/03-code-quality/05-testing-mocha/pow-1.view/index.html index e48a8d3a2..823b95904 100644 --- a/1-js/03-code-quality/05-testing-mocha/pow-1.view/index.html +++ b/1-js/03-code-quality/05-testing-mocha/pow-1.view/index.html @@ -1,18 +1,17 @@ - + - + - + @@ -21,17 +20,17 @@ - + - +
- + diff --git a/1-js/03-code-quality/05-testing-mocha/pow-1.view/test.js b/1-js/03-code-quality/05-testing-mocha/pow-1.view/test.js index 89ba412ed..e78855dc5 100644 --- a/1-js/03-code-quality/05-testing-mocha/pow-1.view/test.js +++ b/1-js/03-code-quality/05-testing-mocha/pow-1.view/test.js @@ -1,6 +1,6 @@ describe("pow", function() { - it("raises to n-th power", function() { + it("eleva a la n-esima potencia", function() { assert.equal(pow(2, 3), 8); }); diff --git a/1-js/03-code-quality/05-testing-mocha/pow-2.view/index.html b/1-js/03-code-quality/05-testing-mocha/pow-2.view/index.html index e8d6be23d..638f3ed06 100644 --- a/1-js/03-code-quality/05-testing-mocha/pow-2.view/index.html +++ b/1-js/03-code-quality/05-testing-mocha/pow-2.view/index.html @@ -1,37 +1,35 @@ - + - + - + - - + - +
- + diff --git a/1-js/03-code-quality/05-testing-mocha/pow-2.view/test.js b/1-js/03-code-quality/05-testing-mocha/pow-2.view/test.js index 9a2f8fde7..82821204a 100644 --- a/1-js/03-code-quality/05-testing-mocha/pow-2.view/test.js +++ b/1-js/03-code-quality/05-testing-mocha/pow-2.view/test.js @@ -1,10 +1,10 @@ describe("pow", function() { - it("2 raised to power 3 is 8", function() { + it("2 elevado a la potencia de 3 es 8", function() { assert.equal(pow(2, 3), 8); }); - it("3 raised to power 3 is 27", function() { + it("3 elevado a la potencia de 3 es 27", function() { assert.equal(pow(3, 3), 27); }); diff --git a/1-js/03-code-quality/05-testing-mocha/pow-3.view/index.html b/1-js/03-code-quality/05-testing-mocha/pow-3.view/index.html index c71b0d5d5..e9c23bec7 100644 --- a/1-js/03-code-quality/05-testing-mocha/pow-3.view/index.html +++ b/1-js/03-code-quality/05-testing-mocha/pow-3.view/index.html @@ -1,18 +1,17 @@ - + - + - + @@ -31,13 +30,13 @@ } - + - +
- + diff --git a/1-js/03-code-quality/05-testing-mocha/pow-3.view/test.js b/1-js/03-code-quality/05-testing-mocha/pow-3.view/test.js index 8663952aa..cbeeca542 100644 --- a/1-js/03-code-quality/05-testing-mocha/pow-3.view/test.js +++ b/1-js/03-code-quality/05-testing-mocha/pow-3.view/test.js @@ -2,7 +2,7 @@ describe("pow", function() { function makeTest(x) { let expected = x * x * x; - it(`${x} in the power 3 is ${expected}`, function() { + it(`${x} elevado a 3 es ${expected}`, function() { assert.equal(pow(x, 3), expected); }); } diff --git a/1-js/03-code-quality/05-testing-mocha/pow-4.view/index.html b/1-js/03-code-quality/05-testing-mocha/pow-4.view/index.html index c71b0d5d5..e9c23bec7 100644 --- a/1-js/03-code-quality/05-testing-mocha/pow-4.view/index.html +++ b/1-js/03-code-quality/05-testing-mocha/pow-4.view/index.html @@ -1,18 +1,17 @@ - + - + - + @@ -31,13 +30,13 @@ } - + - +
- + diff --git a/1-js/03-code-quality/05-testing-mocha/pow-4.view/test.js b/1-js/03-code-quality/05-testing-mocha/pow-4.view/test.js index e5ce2ce43..afe60360f 100644 --- a/1-js/03-code-quality/05-testing-mocha/pow-4.view/test.js +++ b/1-js/03-code-quality/05-testing-mocha/pow-4.view/test.js @@ -1,10 +1,10 @@ describe("pow", function() { - describe("raises x to power 3", function() { + describe("eleva x a la potencia de 3", function() { function makeTest(x) { let expected = x * x * x; - it(`${x} in the power 3 is ${expected}`, function() { + it(`${x} elevado a 3 es ${expected}`, function() { assert.equal(pow(x, 3), expected); }); } diff --git a/1-js/03-code-quality/05-testing-mocha/pow-full.view/index.html b/1-js/03-code-quality/05-testing-mocha/pow-full.view/index.html index 076b1e5a9..7dc3a53d6 100644 --- a/1-js/03-code-quality/05-testing-mocha/pow-full.view/index.html +++ b/1-js/03-code-quality/05-testing-mocha/pow-full.view/index.html @@ -1,18 +1,17 @@ - + - + - + @@ -32,13 +31,13 @@ } - + - +
- + diff --git a/1-js/03-code-quality/05-testing-mocha/pow-full.view/test.js b/1-js/03-code-quality/05-testing-mocha/pow-full.view/test.js index 75ff5e99f..f0b399f6d 100644 --- a/1-js/03-code-quality/05-testing-mocha/pow-full.view/test.js +++ b/1-js/03-code-quality/05-testing-mocha/pow-full.view/test.js @@ -1,10 +1,10 @@ describe("pow", function() { - describe("raises x to power 3", function() { + describe("eleva x a la potencia 3", function() { function makeTest(x) { let expected = x * x * x; - it(`${x} in the power 3 is ${expected}`, function() { + it(`${x} elevado a 3 es ${expected}`, function() { assert.equal(pow(x, 3), expected); }); } @@ -15,11 +15,11 @@ describe("pow", function() { }); - it("if n is negative, the result is NaN", function() { + it("si n es negativo, el resultado es NaN", function() { assert.isNaN(pow(2, -1)); }); - it("if n is not integer, the result is NaN", function() { + it("si n no es un entero, el resultado es NaN", function() { assert.isNaN(pow(2, 1.5)); }); diff --git a/1-js/03-code-quality/05-testing-mocha/pow-min.view/index.html b/1-js/03-code-quality/05-testing-mocha/pow-min.view/index.html index d82a79dca..e5ddaf68b 100644 --- a/1-js/03-code-quality/05-testing-mocha/pow-min.view/index.html +++ b/1-js/03-code-quality/05-testing-mocha/pow-min.view/index.html @@ -1,18 +1,17 @@ - + - + - + @@ -21,17 +20,17 @@ - + - +
- + diff --git a/1-js/03-code-quality/05-testing-mocha/pow-min.view/test.js b/1-js/03-code-quality/05-testing-mocha/pow-min.view/test.js index 89ba412ed..172127905 100644 --- a/1-js/03-code-quality/05-testing-mocha/pow-min.view/test.js +++ b/1-js/03-code-quality/05-testing-mocha/pow-min.view/test.js @@ -1,6 +1,6 @@ describe("pow", function() { - it("raises to n-th power", function() { + it("eleva a la n-ésima potencia", function() { assert.equal(pow(2, 3), 8); }); diff --git a/1-js/03-code-quality/05-testing-mocha/pow-nan.view/index.html b/1-js/03-code-quality/05-testing-mocha/pow-nan.view/index.html index 523ae25ec..d0e6a1a0f 100644 --- a/1-js/03-code-quality/05-testing-mocha/pow-nan.view/index.html +++ b/1-js/03-code-quality/05-testing-mocha/pow-nan.view/index.html @@ -1,18 +1,17 @@ - + - + - + @@ -29,13 +28,13 @@ } - + - +
- + diff --git a/1-js/03-code-quality/05-testing-mocha/pow-nan.view/test.js b/1-js/03-code-quality/05-testing-mocha/pow-nan.view/test.js index 75ff5e99f..7c34ce439 100644 --- a/1-js/03-code-quality/05-testing-mocha/pow-nan.view/test.js +++ b/1-js/03-code-quality/05-testing-mocha/pow-nan.view/test.js @@ -1,10 +1,10 @@ describe("pow", function() { - describe("raises x to power 3", function() { + describe("eleva x a 3", function() { function makeTest(x) { let expected = x * x * x; - it(`${x} in the power 3 is ${expected}`, function() { + it(`${x} elevado a 3 es ${expected}`, function() { assert.equal(pow(x, 3), expected); }); } @@ -15,11 +15,11 @@ describe("pow", function() { }); - it("if n is negative, the result is NaN", function() { + it("si n es negativo, el resultado es NaN", function() { assert.isNaN(pow(2, -1)); }); - it("if n is not integer, the result is NaN", function() { + it("si n no es un entero, el resultado es NaN", function() { assert.isNaN(pow(2, 1.5)); }); From a1b86419cee880aa509a61fd20e192da8378fea7 Mon Sep 17 00:00:00 2001 From: joaquinelio Date: Sun, 21 Jun 2020 11:50:50 -0300 Subject: [PATCH 2/3] 1.3.5 testing // atualiz article by joaquienlio --- .../05-testing-mocha/article.md | 69 +++++++++---------- 1 file changed, 33 insertions(+), 36 deletions(-) diff --git a/1-js/03-code-quality/05-testing-mocha/article.md b/1-js/03-code-quality/05-testing-mocha/article.md index 59472d13a..ecc07685d 100644 --- a/1-js/03-code-quality/05-testing-mocha/article.md +++ b/1-js/03-code-quality/05-testing-mocha/article.md @@ -1,37 +1,34 @@ - # Test automatizados con mocha -Los tests automáticos deben ser considerados como una tarea más. - -Debe ser parte del "conocimiento mínimo" de un/a desarrollador/a. +Los tests automáticos deben ser considerados como una tarea más, y son ampliamente usasdos en proyectos reales. ## ¿Por qué necesitamos tests? -Cuando escribimos una función, normalmente imaginamos qué debe hacer: Para ciertos parámetros, que resultado. +Cuando escribimos una función, normalmente imaginamos qué debe hacer: Para ciertos parámetros, qué resultado. Durante el desarrollo, podemos comprobar la función ejecutándola y comparando el resultado con la salida esperada. Por ejemplo, podemos hacer eso en la consola. -Si algo esta incorrecto -- entonces corregimos el código, ejecutamos de nuevo, comprobamos resultado -- y así sucesivamente hasta que funcione. +Si algo está incorrecto -- entonces corregimos el código, ejecutamos de nuevo, comprobamos resultado -- y así sucesivamente hasta que funcione. -Pero esa "re-ejecuciones" manuales son imperfectas. +Pero esas "re-ejecuciones" manuales son imperfectas. **Cuando testeamos un código re-ejecutándolo manualmente es fácil obviar algo.** -Por ejemplo, si estamos creando una función `f`. Escribimos algo de código, testeamos: `f(1)` funciona, pero `f(2)` no funciona. Corregimos el código y ahora funciona `f(2)`. ¿Está completo? Hemos olvidado re-testear `f(1)`. Esto puede resultar error. +Por ejemplo, estamos creando una función `f`. Escribimos algo de código, testeamos: `f(1)` funciona, pero `f(2)` no funciona. Corregimos el código y ahora funciona `f(2)`. ¿Está completo? Hemos olvidado re-testear `f(1)`. Esto puede resultar error. Todo esto es muy típico. Cuando desarrollamos algo, mantenemos muchos casos de uso posibles en la cabeza. Pero es complicado esperar que un/a programador/a compruebe todos después de cada cambio. Por lo que deviene fácil arreglar una cosa y romper otra. -**Los tests automatizados implican escribir los tests por separado, además del código. Pueden ser ejecutados fácilmente y comprueban todos los casos de uso principales.** +**Los tests automatizados implican escribir los tests por separado, además del código. Ellos ejecutan nuestras funciones de varias formas y comparan los resultados con los esperados.** -## Behavior Driven Development (BDD) +## Desarrollo guiado por comportamiento (Behavior Driven Development, BDD) -Vamos a usar una técnica llamada [Desarrollo guiado por comportamiento](http://en.wikipedia.org/wiki/Behavior-driven_development) o por sus siglas en inglés, BDD. Es una aproximación utilizada en muchos proyectos. BDD no es solo hacer test. Es más. +Vamos a usar una técnica llamada [Desarrollo guiado por comportamiento](https://es.wikipedia.org/wiki/Desarrollo_guiado_por_comportamiento) o por sus siglas en inglés, BDD. **BDD son tres cosas en uno: tests, documentación y ejemplos.** -Basta de palabras, veamos un ejemplo: +PAra entender BDD, examinaremos un caso de desarrollo práctico: -## Desarrollo de "potencia de un número (pow)": la especificación +## Desarrollo de potencia de un número "pow": la especificación Digamos que queremos hacer una función `pow(x, n)` que eleve `x` a la potencia de un entero `n`. Asumimos que `n≥0`. @@ -39,7 +36,8 @@ Esta tarea es sólo un ejemplo: Hay un operador `**` en JavaScript que hace eso, Antes de crear el código de `pow`, podemos imaginar lo que hace la función y describirlo. -Esa descripción es llamada *especificación* o una spec y se asemeja a: +Esa descripción es llamada *especificación* o "spec" y contiene las descripciones de uso junto con los test para probarlas, como: + ```js describe("pow", function() { @@ -53,7 +51,7 @@ describe("pow", function() { Una spec tiene los tres bloques principales mostrados abajo: `describe("titulo", function() { ... })` -: Qué funcionalidad estamos describiendo. Utilizado para agrupar los "trabajadores" -- los bloques `it`. En nuestro caso estamos describiendo la función `pow`. +: Qué funcionalidad estamos describiendo. En nuestro caso estamos describiendo la función `pow`. Utilizado para agrupar los "workers" (trabajadores) -- los bloques `it`. `it("titulo", function() { ... })` : En el título de `it` introducimos una descripción entendible en forma humana del caso de uso. El segundo argumento es la función que testea eso. @@ -61,9 +59,9 @@ Una spec tiene los tres bloques principales mostrados abajo: `assert.equal(value1, value2)` : El código dentro del bloque `it`, si la implementación es correcta, debe ejecutar sin errores. - Las funciones `assert.*` son usadas para comprobar cuando `pow` funciona como esperamos. Justo aquí utilizamos una de ellas -- `assert.equal`, que compara argumentos y produce un error si los mismos no son iguales. Arriba se está comprobando que el resultado de `pow(2, 3)` es igual a `8`. + Las funciones `assert.*` son usadas para comprobar cuando `pow` funciona como esperamos. Justo aquí utilizamos una de ellas -- `assert.equal`, que compara argumentos y produce un error si los mismos no son iguales. Arriba se está comprobando que el resultado de `pow(2, 3)` sea igual a `8`. Hay otros tipos de comparaciones y comprobaciones que veremos más adelante. - Hay otros tipos de comparaciones y comprobaciones que veremos más adelante. +La especificación puede ser ejecutada, y hará los los test dictados en el bloque `it`. Lo veremos luego. ## El flujo de desarrollo @@ -71,7 +69,7 @@ El flujo de desarrollo podría asemejarse a: 1. Un spec inicial es escrito, con tests para la funcionalidad más básica. 2. Una implementación inicial es creada. -3. Para comprobar que funciona, ejecutamos el framework de test [Mocha](http://mochajs.org/) (detallado más adelante) que ejecuta el spec. Los errores son mostrados. Hacemos correcciones hasta que todo funciona. +3. Para comprobar que funciona, ejecutamos el framework de test [Mocha](http://mochajs.org/) (detallado más adelante) que ejecuta el spec. Mostrará los errores mientras la funcionalidad no esté completa. Hacemos correcciones hasta que todo funciona. 4. Ahora tenemos una implementación inicial con tests. 5. Añadimos más casos de uso al spec, seguramente no soportados aún por la implementación. Los tests empiezan a fallar. 6. Ir a 3, actualizar la implementación hasta que los tests no den errores. @@ -79,7 +77,9 @@ El flujo de desarrollo podría asemejarse a: De tal forma que el desarrollo es iterativo. Escribimos la especificación, la implementamos, aseguramos que los tests pasen y entonces escribimos más tests y volvemos a asegurar que pasen, etc. Al final tenemos una implementación funcionando con tests para ella. -En nuestro caso, el primer paso esta completo: tenemos una spec inicial para `pow`. Vamos a realizar la implementación. Pero antes de comenzar hemos de asegurarnos que los test se ejecutan (no hay errores de sintáxis ni de compilación pero van a fallar todos). +Veamos el flujo de desarrollo en nuestro caso práctico. + +El primer paso esta completo: tenemos una spec inicial para `pow`. Ahora, antes de realizar la implementación, usamos algunas librería JavaScript para ejecutar los tests, solo para asegurarnos que funcionen (van a fallar todos). ## La spec en acción @@ -99,7 +99,7 @@ La página HTML con estos frameworks y la spec de `pow`: La página puede ser dividida en cinco partes: 1. El `` -- importa librerías de terceros y estilos para los tests. -2. El `