From c82f0f10fc894215c69afc6ff09fca5899180497 Mon Sep 17 00:00:00 2001
From: alexseik <alexseik@hotmail.com>
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 `<head>` -- add third-party libraries and styles for tests.
-2. The `<script>` with the function to test, in our case -- with the code for `pow`.
-3. The tests -- in our case an external script `test.js` that has `describe("pow", ...)` from above.
-4. The HTML element `<div id="mocha">` will be used by Mocha to output results.
-5. The tests are started by the command `mocha.run()`.
+1. El `<head>` -- importa librerías de terceros y estilos para los tests.
+2. El `<script>` con la función a comprobar, en nuesro caso -- cont el código de `pow`.
+3. Los tests -- en nuestro caso un fichero externo `test.js` que contiene un sentencia `describe("pow", ...)`al inicio.
+4. El elemento HTML `<div id="mocha">` utilizado para la salida de los resultados.
+5. Los test se inician con el comando `mocha.run()`.
 
-The result:
+El resultado:
 
 [iframe height=250 src="pow-1" border=1 edit]
 
-As of now, the test fails, there's an error. That's logical: we have an empty function code in `pow`, so `pow(2,3)` returns `undefined` instead of `8`.
+De momento, el test falla. Es lógico: tenemos el código vacío en la función `pow`, así que `pow(2,3)` devuelve `undefined` en lugar de `8`.
 
-For the future, let's note that there are advanced test-runners, like [karma](https://karma-runner.github.io/) and others. So it's generally not a problem to setup many different tests.
+Para más adelante, ten en cuenta que hay avanzados test-runners (Herramientas para ejecutar los test en diferentes entornos de forma automática), como [karma](https://karma-runner.github.io/) y otros. Por lo que generalmente no es un problema configurar muchos tests diferentes.
 
-## Initial implementation
+## Implementación inicial
 
-Let's make a simple implementation of `pow`, for tests to pass:
+Vamos a realizar una implementación simple de `pow`, suficiente para pasar el test:
 
 ```js
 function pow(x, n) {
-  return 8; // :) we cheat!
+  return 8; // :) ¡hacemos trampas!
 }
 ```
 
-Wow, now it works!
+¡Ahora funciona!
 
 [iframe height=250 src="pow-min" border=1 edit]
 
-## Improving the spec
+## Mejoramos el spec
 
-What we've done is definitely a cheat. The function does not work: an attempt to calculate `pow(3,4)` would give an incorrect result, but tests pass.
+Lo que hemos hecho es una trampa. La función no funciona bien: ejecutar un cálculo diferente como   `pow(3,4)` nos devuelve un resultado incorrecto pero el test pasa.
 
-...But the situation is quite typical, it happens in practice. Tests pass, but the function works wrong. Our spec is imperfect. We need to add more use cases to it.
+... pero la situación es habitual, ocurre en la práctica. Los tests pasan, pero la función no funciona bien. Nuestra especificación está incompleta. Necesitamos añadir más casos de uso a la especificación.
 
-Let's add one more test to see if `pow(3, 4) = 81`.
+Vamos a incluir un test para ver si `pow(3,4) = 81`.
 
-We can select one of two ways to organize the test here:
+Podemos escoger entre dos formas de organizar el test:
 
-1. The first variant -- add one more `assert` into the same `it`:
+1. La primera manera -- añadir un `assert` más en el mismo `it`:
 
     ```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);
     *!*
         assert.equal(pow(3, 4), 81);
@@ -150,43 +149,43 @@ We can select one of two ways to organize the test here:
 
     });
     ```
-2. The second -- make two tests:
+2. La segunda -- hacer dos tests:
 
     ```js
     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);
       });
 
     });
     ```
 
-The principal difference is that when `assert` triggers an error, the `it` block immediately terminates. So, in the first variant if the first `assert` fails, then we'll never see the result of the second `assert`.
+La diferencia principal se da cuando `assert` lanza un error, el bloque `it` termina inmediatamente. De forma que si en la primera manera el primer `assert` falla, no veremos nunca el resultado del segundo `assert`.
 
-Making tests separate is useful to get more information about what's going on, so the second variant is better.
+Hacer los tests separados es útil para recoger información sobre qué está pasando, de forma que la segunda manera es mejor.
 
-And besides that, there's one more rule that's good to follow.
+A parte de eso, hay otra regla que es bueno seguir.
 
-**One test checks one thing.**
+**Un test comprueba una sola cosa**
 
-If we look at the test and see two independent checks in it, it's better to split it into two simpler ones.
+Si vemos que un test contiene dos comprobaciones independientes, es mejor separar el test en dos tests más simples.
 
-So let's continue with the second variant.
+Así que continuamos con la segunda manera.
 
-The result:
+El resultado:
 
 [iframe height=250 src="pow-2" edit border="1"]
 
-As we could expect, the second test failed. Sure, our function always returns `8`, while the `assert` expects `27`.
+Como podemos esperar, el segundo falla. Nuestra función siempre devuelve `8` mientras el `assert` espera `27`.
 
-## Improving the implementation
+## Mejoramos la implementación
 
-Let's write something more real for tests to pass:
+Vamos a escribir algo más real para que pasen los tests:
 
 ```js
 function pow(x, n) {
@@ -200,14 +199,14 @@ function pow(x, n) {
 }
 ```
 
-To be sure that the function works well, let's test it for more values. Instead of writing `it` blocks manually, we can generate them in `for`:
+Para estar seguros que la función trabaja bien, vamos a hacer comprobaciones para más valores. En lugar de escribir bloques `it`s manualmente, vamos a generarlos con un `for`:
 
 ```js
 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);
     });
   }
@@ -219,26 +218,26 @@ describe("pow", function() {
 });
 ```
 
-The result:
+El resultado:
 
 [iframe height=250 src="pow-3" edit border="1"]
 
-## Nested describe
+## `Describe` anidados
 
-We're going to add even more tests. But before that let's note that the helper function `makeTest` and `for` should be grouped together. We won't need `makeTest` in other tests, it's needed only in `for`: their common task is to check how `pow` raises into the given power.
+Vamos a añadir más tests. Pero antes, hay que apuntar que la función `makeTest` y la instrución `for` deben ser agrupados juntos. No queremos `makeTest` en otros tests, solo se necesita en el `for`: su tarea común es comprobar cómo `pow` eleva dad una potencia concreta.
 
-Grouping is done with a nested `describe`:
+Agrupar tests se realiza con `describe`:
 
 ```js
 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);
       });
     }
@@ -251,29 +250,29 @@ describe("pow", function() {
   });
 */!*
 
-  // ... more tests to follow here, both describe and it can be added
+  // ... otros test irían aquí, se puede escribir describe como it
 });
 ```
 
-The nested `describe` defines a new "subgroup" of tests. In the output we can see the titled indentation:
+El `describe` anidado define un nuevo subgrupo de tests. En la salida podemos ver la identación en los títulos:
 
 [iframe height=250 src="pow-4" edit border="1"]
 
-In the future we can add more `it` and `describe` on the top level with helper functions of their own, they won't see `makeTest`.
+En el futuro podemos añadir más `it` y `describe` en el primer nivel con funciones de ayuda para ellos mismos, no se solaparán con `makeTest`.
 
-````smart header="`before/after` and `beforeEach/afterEach`"
-We can setup `before/after` functions that execute before/after running tests, and also `beforeEach/afterEach` functions that execute before/after *every* `it`.
+````smart header="`before/after` y `beforeEach/afterEach`"
+Podemos configurar funciones `before/after` que se ejecuten antes/después de la ejecución de los tests, y también funciones `beforeEach/afterEach` que ejecuten antes/después de cada `it`.
 
-For instance:
+Por ejemplo:
 
 ```js no-beautify
 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));
@@ -281,46 +280,46 @@ describe("test", function() {
 });
 ```
 
-The running sequence will be:
+La secuencia que se ejecuta es la siguiente:
 
 ```
-Testing started – before all tests (before)
-Before a test – enter a test (beforeEach)
+Inicio testing – antes de todos los tests (before)
+Antes de un test – entramos al test (beforeEach)
 1
-After a test – exit a test   (afterEach)
-Before a test – enter a test (beforeEach)
+Después de un test – salimos del test   (afterEach)
+Antes de un test – entramos al test (beforeEach)
 2
-After a test – exit a test   (afterEach)
-Testing finished – after all tests (after)
+Después de un test – salimos del test   (afterEach)
+Final testing – después de todos los tests (after)
 ```
 
-[edit src="beforeafter" title="Open the example in the sandbox."]
+[edit src="beforeafter" title="Abre el ejemplo en un sandbox."]
 
-Usually, `beforeEach/afterEach` (`before/after`) are used to perform initialization, zero out counters or do something else between the tests (or test groups).
+Normalmente, `beforeEach/afterEach` (`before/after`) son usados para realizar la inicialización, poner contadores a cero o hacer algo entre cada test o cada grupo de tests.
 ````
 
-## Extending the spec
+## Extender los spec
 
-The basic functionality of `pow` is complete. The first iteration of the development is done. When we're done celebrating and drinking champagne -- let's go on and improve it.
+La funcionalidad básica de `pow` está completa. La primera iteracción del desarrollo está hecha. Cuando acabemos de celebrar y beber champán -- sigamos adelante y mejorémosla.
 
-As it was said, the function `pow(x, n)` is meant to work with positive integer values `n`.
+Como se dijo, la función `pow(x, n)` está dedicada a trabajar con valores enteros positivos `n`.
 
-To indicate a mathematical error, JavaScript functions usually return `NaN`. Let's do the same for invalid values of `n`.
+Para indicar un error matemático, JavaScript normalmente devuelve `NaN` como resultado de una función. Hagamos lo mismo para valores incorrectos de `n`.
 
-Let's first add the behavior to the spec(!):
+Primero incluyamos el comportamiento en el spec(!):
 
 ```js
 describe("pow", function() {
 
   // ...
 
-  it("for negative n the result is NaN", function() {
+  it("para n negativos el resultado es NaN", function() {
 *!*
     assert.isNaN(pow(2, -1));
 */!*
   });
 
-  it("for non-integer n the result is NaN", function() {
+  it("para no enteros el resultado is NaN", function() {
 *!*
     assert.isNaN(pow(2, 1.5));    
 */!*
@@ -329,27 +328,27 @@ describe("pow", function() {
 });
 ```
 
-The result with new tests:
+El resultado con los nuevos tests:
 
 [iframe height=530 src="pow-nan" edit border="1"]
 
-The newly added tests fail, because our implementation does not support them. That's how BDD is done: first we write failing tests, and then make an implementation for them.
+El test recién creado falla, porque nuestra implementación no lo soporta. Así es como funciona la metodología BDD: primero escribimos un test que falle y luego realizamos la implementación para que pase.
 
-```smart header="Other assertions"
+```smart header="Otras comprobaciones"
 
-Please note the assertion `assert.isNaN`: it checks for `NaN`.
+Por favor, ten en cuenta la comprobación `assert.isNaN`: ella comprueba que el valor es `NaN`.
 
-There are other assertions in Chai as well, for instance:
+Hay otras comprobaciones en Chai también, por ejemplo:
 
-- `assert.equal(value1, value2)` -- checks the equality  `value1 == value2`.
-- `assert.strictEqual(value1, value2)` -- checks the strict equality `value1 === value2`.
-- `assert.notEqual`, `assert.notStrictEqual` -- inverse checks to the ones above.
-- `assert.isTrue(value)` -- checks that `value === true`
-- `assert.isFalse(value)` -- checks that `value === false`
-- ...the full list is in the [docs](http://chaijs.com/api/assert/)
+- `assert.equal(value1, value2)` -- prueba la igualdad  `value1 == value2`.
+- `assert.strictEqual(value1, value2)` -- prueba la igualdad estricta `value1 === value2`.
+- `assert.notEqual`, `assert.notStrictEqual` -- el contrario que arriba.
+- `assert.isTrue(value)` -- prueba que `value === true`
+- `assert.isFalse(value)` -- prueba que `value === false`
+- ... la lista entera se puede encontrar en [docs](http://chaijs.com/api/assert/)
 ```
 
-So we should add a couple of lines to `pow`:
+Así que podemos añadir un par de líneas a `pow`:
 
 ```js
 function pow(x, n) {
@@ -368,45 +367,45 @@ function pow(x, n) {
 }
 ```
 
-Now it works, all tests pass:
+Ahora funciona y todos los tests pasan:
 
 [iframe height=300 src="pow-full" edit border="1"]
 
-[edit src="pow-full" title="Open the full final example in the sandbox."]
+[edit src="pow-full" title="Abre el ejemplo final en un sandbox."]
 
-## Summary
+## Resumen
 
-In BDD, the spec goes first, followed by implementation. At the end we have both the spec and the code.
+En BDD, la especificación va primero, seguida de la implementación. Al final tenemos tanto la especificación como la implementación.
 
-The spec can be used in three ways:
+El spec puede ser usado de tres formas:
 
-1. **Tests** guarantee that the code works correctly.
-2. **Docs** -- the titles of `describe` and `it` tell what the function does.
-3. **Examples** -- the tests are actually working examples showing how a function can be used.
+1. **Tests** garantizan que el código funciona correctamente.
+2. **Docs** -- los títulos de los `describe` e `it` nos dicen que hacen la función.
+3. **Ejemplos** -- los tests son también ejemplos funcionales que muestran como una función puede ser usada.
 
-With the spec, we can safely improve, change, even rewrite the function from scratch and make sure it still works right.
+Con la especificación, podemos mejorar de forma segura, cambiar, incluso reescribir la función desde cero y estar seguros que seguirá funcionando.
 
-That's especially important in large projects when a function is used in many places. When we change such a function, there's just no way to manually check if every place that uses it still works right.
+Esto es especialmente importante en proyectos largos cuando una función es usada en muchos sitios. Cuando cambiamos una función, no hay forma manual de comprobar si cada sitio dónde se usaba sigue funcionando correctamente.
 
-Without tests, people have two ways:
+Sin tests, la gente tiene dos maneras:
 
-1. To perform the change, no matter what. And then our users meet bugs and report them. If we can afford that.
-2. Or people become afraid to modify such functions, if the punishment for errors is harsh. Then it becomes old, overgrown with cobwebs, no one wants to get into it, and that's not good.
+1. Realizar el cambio, no importa nada más. Luegos los usuarios encontrán errores y deberán notificarlos. Si podemos abordarlo.
+2. La gente tiene miedo de cambiar funciones si el castigo por error es duro. Entonces el código envejecerá de forma descuidada con telarañas, nadie querrá meterse en él y eso no es bueno.
 
-**Automatically tested code is contrary to that!**
+**¡Las pruebas automáticas son lo contrario a eso!**
 
-If the project is covered with tests, there's just no such problem. We can run tests and see a lot of checks made in a matter of seconds.
+Si el proyecto esta cubierto de pruebas, no tendremos ese problema. Podemos correr los tests y hacer multitud de comprabaciones en cuestión de segundos.
 
-**Besides, a well-tested code has better architecture.**
+**Además, un código bien probado tendrá una mejor arquitectura.**
 
-Naturally, that's because it's easier to change and improve it. But not only that.
+Naturalmente, porque el código será más fácil de cambiar y mejorar. Pero no sólo eso.
 
-To write tests, the code should be organized in such a way that every function has a clearly described task, well-defined input and output. That means a good architecture from the beginning.
+Al escribir tests, el código debe estar organizado de tal manera que cada función tenga un propósito claro y explícito, una entrada y una salida bien definida. Eso implica una buena arquitectura desde el principio.
 
-In real life that's sometimes not that easy. Sometimes it's difficult to write a spec before the actual code, because it's not yet clear how it should behave. But in general writing tests makes development faster and more stable.
+En la vida real a veces las cosas no son tan fáciles. A veces, es difícil escribir una especificación antes que el código, porque no esta claro aún cómo dee comportarse dicho código. Pero en general, escribir los tests hace el desarrollo más rápido y más estable.
 
-## What now?
+## ¿Qué viene ahora?
 
-Later in the tutorial you will meet many tasks with tests baked-in. So you'll see more practical examples.
+Al final en el tutorial encontrarás muchas tareas respaldadas con pruebas. Ahí tenemos más ejemplos prácticos de tests.
 
-Writing tests requires good JavaScript knowledge. But we're just starting to learn it. So, to settle down everything, as of now you're not required to write tests, but you should already be able to read them even if they are a little bit more complex than in this chapter.
+Escribir tests requiere un buen conocimiento de JavaScript. Pero nosotros justo acabamos de empezar a aprenderlo. Así que para comenzar no es necesario que escribas tests, pero sí que seas capaz de leerlos y entenderlos, incluso ejemplos más complejos que aparecerán más adelante en este capítulo.
diff --git a/1-js/03-code-quality/05-testing-mocha/beforeafter.view/index.html b/1-js/03-code-quality/05-testing-mocha/beforeafter.view/index.html
index e680b536b..80a9c4f94 100644
--- a/1-js/03-code-quality/05-testing-mocha/beforeafter.view/index.html
+++ b/1-js/03-code-quality/05-testing-mocha/beforeafter.view/index.html
@@ -1,31 +1,30 @@
 <!DOCTYPE html>
 <html>
 <head>
-  <!-- add mocha css, to show results -->
+  <!-- incluir css para mocha, para mostrar los resultados -->
   <link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/mocha/3.2.0/mocha.css">
-  <!-- add mocha framework code -->
+  <!-- incluir el código del framework mocha -->
   <script src="https://cdnjs.cloudflare.com/ajax/libs/mocha/3.2.0/mocha.js"></script>
   <script>
-    // enable bdd-style testing
-    mocha.setup('bdd');
+    mocha.setup('bdd'); // configuración mínima
   </script>
-  <!-- add chai -->
+  <!-- incluir chai -->
   <script src="https://cdnjs.cloudflare.com/ajax/libs/chai/3.5.0/chai.js"></script>
   <script>
-    // chai has a lot of stuff, let's make assert global
+    // chai tiene un montón de cosas, hacemos assert global
     let assert = chai.assert;
   </script>
 </head>
 
 <body>
 
-  <!-- the script with tests (describe, it...) -->
+  <!-- el fichero con los tests (describe, it...) -->
   <script src="test.js"></script>
 
-  <!-- the element with id="mocha" will contain test results -->
+  <!-- el elemento con id="mocha" que contendrá los resultados de los tests -->
   <div id="mocha"></div>
 
-  <!-- run tests! -->
+  <!-- ¡ejecutamos los tests! -->
   <script>
     mocha.run();
   </script>
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 @@
 <!DOCTYPE html>
 <html>
 <head>
-  <!-- add mocha css, to show results -->
+  <!-- incluir css para mocha, para mostrar los resultados -->
   <link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/mocha/3.2.0/mocha.css">
-  <!-- add mocha framework code -->
+  <!-- incluir el código del framework mocha -->
   <script src="https://cdnjs.cloudflare.com/ajax/libs/mocha/3.2.0/mocha.js"></script>
   <script>
-    mocha.setup('bdd'); // minimal setup
+    mocha.setup('bdd'); // configuración mínima
   </script>
-  <!-- add chai -->
+  <!-- incluir chai -->
   <script src="https://cdnjs.cloudflare.com/ajax/libs/chai/3.5.0/chai.js"></script>
   <script>
-    // chai has a lot of stuff, let's make assert global
+    // chai tiene un montón de cosas, hacemos assert global
     let assert = chai.assert;
   </script>
 </head>
@@ -20,17 +20,17 @@
 
   <script>
     function pow(x, n) {
-      /* function code is to be written, empty now */
+      /* código a escribir de la función, de momento vacío */
     }
   </script>
 
-  <!-- the script with tests (describe, it...) -->
+  <!-- el script con los tests (describe, it...) -->
   <script src="test.js"></script>
 
-  <!-- the element with id="mocha" will contain test results -->
+  <!-- el elemento con id="mocha" que contiene los resultados de los tests -->
   <div id="mocha"></div>
 
-  <!-- run tests! -->
+  <!-- ¡ejectuar los tests! -->
   <script>
     mocha.run();
   </script>
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 @@
 <!DOCTYPE html>
 <html>
 <head>
-  <!-- add mocha css, to show results -->
+  <!-- incluir css para mocha, para mostrar los resultados -->
   <link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/mocha/3.2.0/mocha.css">
-  <!-- add mocha framework code -->
+  <!-- incluir el código del framework mocha -->
   <script src="https://cdnjs.cloudflare.com/ajax/libs/mocha/3.2.0/mocha.js"></script>
   <script>
-    // enable bdd-style testing
-    mocha.setup('bdd');
+    mocha.setup('bdd'); // configuración mínima
   </script>
-  <!-- add chai -->
+  <!-- incluir chai -->
   <script src="https://cdnjs.cloudflare.com/ajax/libs/chai/3.5.0/chai.js"></script>
   <script>
-    // chai has a lot of stuff, let's make assert global
+    // chai tiene un montón de cosas, hacemos assert global
     let assert = chai.assert;
   </script>
 </head>
@@ -21,17 +20,17 @@
 
   <script>
     function pow(x, n) {
-      /* function code is to be written, empty now */
+      /* código a escribir de la función, de momento vacío */
     }
   </script>
 
-  <!-- the script with tests (describe, it...) -->
+  <!-- el script con los tests (describe, it...) -->
   <script src="test.js"></script>
 
-  <!-- the element with id="mocha" will contain test results -->
+  <!-- el elemento con id="mocha" que contiene los resultados de los tests -->
   <div id="mocha"></div>
 
-  <!-- run tests! -->
+  <!-- ¡ejectuar los tests! -->
   <script>
     mocha.run();
   </script>
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 @@
 <!DOCTYPE html>
 <html>
 <head>
-  <!-- add mocha css, to show results -->
+  <!-- incluir css para mocha, para mostrar los resultados -->
   <link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/mocha/3.2.0/mocha.css">
-  <!-- add mocha framework code -->
+  <!-- incluir el código del framework mocha -->
   <script src="https://cdnjs.cloudflare.com/ajax/libs/mocha/3.2.0/mocha.js"></script>
   <script>
-    // enable bdd-style testing
-    mocha.setup('bdd');
+    mocha.setup('bdd'); // configuración mínima
   </script>
-  <!-- add chai -->
+  <!-- incluir chai -->
   <script src="https://cdnjs.cloudflare.com/ajax/libs/chai/3.5.0/chai.js"></script>
   <script>
-    // chai has a lot of stuff, let's make assert global
+    // chai tiene un montón de cosas, hacemos assert global
     let assert = chai.assert;
   </script>
 </head>
-
 <body>
 
   <script>
     function pow(x, n) {
-      return 8; // :) we cheat!
+      return 8; // :) ¡hacemos trampas!
     }
   </script>
 
-  <!-- the script with tests (describe, it...) -->
+  <!-- el fichero con los tests (describe, it...) -->
   <script src="test.js"></script>
 
-  <!-- the element with id="mocha" will contain test results -->
+  <!-- el elemento con id="mocha" que contendrá los resultados de los tests -->
   <div id="mocha"></div>
 
-  <!-- run tests! -->
+  <!-- ¡ejecutamos los tests! -->
   <script>
     mocha.run();
   </script>
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 @@
 <!DOCTYPE html>
 <html>
 <head>
-  <!-- add mocha css, to show results -->
+  <!-- incluir css para mocha, para mostrar los resultados -->
   <link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/mocha/3.2.0/mocha.css">
-  <!-- add mocha framework code -->
+  <!-- incluir el código del framework mocha -->
   <script src="https://cdnjs.cloudflare.com/ajax/libs/mocha/3.2.0/mocha.js"></script>
   <script>
-    // enable bdd-style testing
-    mocha.setup('bdd');
+    mocha.setup('bdd'); // configuración mínima
   </script>
-  <!-- add chai -->
+  <!-- incluir chai -->
   <script src="https://cdnjs.cloudflare.com/ajax/libs/chai/3.5.0/chai.js"></script>
   <script>
-    // chai has a lot of stuff, let's make assert global
+    // chai tiene un montón de cosas, hacemos assert global
     let assert = chai.assert;
   </script>
 </head>
@@ -31,13 +30,13 @@
     }
   </script>
 
-  <!-- the script with tests (describe, it...) -->
+  <!-- el fichero con los tests (describe, it...) -->
   <script src="test.js"></script>
 
-  <!-- the element with id="mocha" will contain test results -->
+  <!-- el elemento con id="mocha" que contendrá los resultados de los tests -->
   <div id="mocha"></div>
 
-  <!-- run tests! -->
+  <!-- ¡ejecutamos los tests! -->
   <script>
     mocha.run();
   </script>
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 @@
 <!DOCTYPE html>
 <html>
 <head>
-  <!-- add mocha css, to show results -->
+  <!-- incluir css para mocha, para mostrar los resultados -->
   <link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/mocha/3.2.0/mocha.css">
-  <!-- add mocha framework code -->
+  <!-- incluir el código del framework mocha -->
   <script src="https://cdnjs.cloudflare.com/ajax/libs/mocha/3.2.0/mocha.js"></script>
   <script>
-    // enable bdd-style testing
-    mocha.setup('bdd');
+    mocha.setup('bdd'); // configuración mínima
   </script>
-  <!-- add chai -->
+  <!-- incluir chai -->
   <script src="https://cdnjs.cloudflare.com/ajax/libs/chai/3.5.0/chai.js"></script>
   <script>
-    // chai has a lot of stuff, let's make assert global
+    // chai tiene un montón de cosas, hacemos assert global
     let assert = chai.assert;
   </script>
 </head>
@@ -31,13 +30,13 @@
     }
   </script>
 
-  <!-- the script with tests (describe, it...) -->
+  <!-- el fichero con los tests (describe, it...) -->
   <script src="test.js"></script>
 
-  <!-- the element with id="mocha" will contain test results -->
+  <!-- el elemento con id="mocha" que contendrá los resultados de los tests -->
   <div id="mocha"></div>
 
-  <!-- run tests! -->
+  <!-- ¡ejecutamos los tests! -->
   <script>
     mocha.run();
   </script>
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 @@
 <!DOCTYPE html>
 <html>
 <head>
-  <!-- add mocha css, to show results -->
+  <!-- incluir css para mocha, para mostrar los resultados -->
   <link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/mocha/3.2.0/mocha.css">
-  <!-- add mocha framework code -->
+  <!-- incluir el código del framework mocha -->
   <script src="https://cdnjs.cloudflare.com/ajax/libs/mocha/3.2.0/mocha.js"></script>
   <script>
-    // enable bdd-style testing
-    mocha.setup('bdd');
+    mocha.setup('bdd'); // configuración mínima
   </script>
-  <!-- add chai -->
+  <!-- incluir chai -->
   <script src="https://cdnjs.cloudflare.com/ajax/libs/chai/3.5.0/chai.js"></script>
   <script>
-    // chai has a lot of stuff, let's make assert global
+    // chai tiene un montón de cosas, hacemos assert global
     let assert = chai.assert;
   </script>
 </head>
@@ -32,13 +31,13 @@
     }
   </script>
 
-  <!-- the script with tests (describe, it...) -->
+  <!-- el fichero con los tests (describe, it...) -->
   <script src="test.js"></script>
 
-  <!-- the element with id="mocha" will contain test results -->
+  <!-- el elemento con id="mocha" que contendrá los resultados de los tests -->
   <div id="mocha"></div>
 
-  <!-- run tests! -->
+  <!-- ¡ejecutamos los tests! -->
   <script>
     mocha.run();
   </script>
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 @@
 <!DOCTYPE html>
 <html>
 <head>
-  <!-- add mocha css, to show results -->
+  <!-- incluir css para mocha, para mostrar los resultados -->
   <link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/mocha/3.2.0/mocha.css">
-  <!-- add mocha framework code -->
+  <!-- incluir el código del framework mocha -->
   <script src="https://cdnjs.cloudflare.com/ajax/libs/mocha/3.2.0/mocha.js"></script>
   <script>
-    // enable bdd-style testing
-    mocha.setup('bdd');
+    mocha.setup('bdd'); // configuración mínima
   </script>
-  <!-- add chai -->
+  <!-- incluir chai -->
   <script src="https://cdnjs.cloudflare.com/ajax/libs/chai/3.5.0/chai.js"></script>
   <script>
-    // chai has a lot of stuff, let's make assert global
+    // chai tiene un montón de cosas, hacemos assert global
     let assert = chai.assert;
   </script>
 </head>
@@ -21,17 +20,17 @@
 
   <script>
     function pow() {
-      return 8; // :) we cheat!
+      return 8; // :) ¡hacemos trampas!
     }
   </script>
 
-  <!-- the script with tests (describe, it...) -->
+  <!-- el fichero con los tests (describe, it...) -->
   <script src="test.js"></script>
 
-  <!-- the element with id="mocha" will contain test results -->
+  <!-- el elemento con id="mocha" que contendrá los resultados de los tests -->
   <div id="mocha"></div>
 
-  <!-- run tests! -->
+  <!-- ¡ejecutamos los tests! -->
   <script>
     mocha.run();
   </script>
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 @@
 <!DOCTYPE html>
 <html>
 <head>
-  <!-- add mocha css, to show results -->
+  <!-- incluir css para mocha, para mostrar los resultados -->
   <link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/mocha/3.2.0/mocha.css">
-  <!-- add mocha framework code -->
+  <!-- incluir el código del framework mocha -->
   <script src="https://cdnjs.cloudflare.com/ajax/libs/mocha/3.2.0/mocha.js"></script>
   <script>
-    // enable bdd-style testing
-    mocha.setup('bdd');
+    mocha.setup('bdd'); // configuración mínima
   </script>
-  <!-- add chai -->
+  <!-- incluir chai -->
   <script src="https://cdnjs.cloudflare.com/ajax/libs/chai/3.5.0/chai.js"></script>
   <script>
-    // chai has a lot of stuff, let's make assert global
+    // chai tiene un montón de cosas, hacemos assert global
     let assert = chai.assert;
   </script>
 </head>
@@ -29,13 +28,13 @@
     }
   </script>
 
-  <!-- the script with tests (describe, it...) -->
+  <!-- el fichero con los tests (describe, it...) -->
   <script src="test.js"></script>
 
-  <!-- the element with id="mocha" will contain test results -->
+  <!-- el elemento con id="mocha" que contendrá los resultados de los tests -->
   <div id="mocha"></div>
 
-  <!-- run tests! -->
+  <!-- ¡ejecutamos los tests! -->
   <script>
     mocha.run();
   </script>
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 <joaquinelio@gmail.com>
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 `<head>` -- importa librerías de terceros y estilos para los tests.
-2. El `<script>` con la función a comprobar, en nuesro caso -- cont el código de `pow`.
+2. El `<script>` con la función a comprobar, en nuesro caso -- con el código de `pow`.
 3. Los tests -- en nuestro caso un fichero externo `test.js` que contiene un sentencia `describe("pow", ...)`al inicio.
 4. El elemento HTML `<div id="mocha">` utilizado para la salida de los resultados.
 5. Los test se inician con el comando `mocha.run()`.
@@ -200,7 +200,7 @@ function pow(x, n) {
 }
 ```
 
-Para estar seguros que la función trabaja bien, vamos a hacer comprobaciones para más valores. En lugar de escribir bloques `it`s manualmente, vamos a generarlos con un `for`:
+Para estar seguros de que la función trabaja bien, vamos a hacer comprobaciones para más valores. En lugar de escribir bloques `it`s manualmente, vamos a generarlos con un `for`:
 
 ```js
 describe("pow", function() {
@@ -225,7 +225,7 @@ El resultado:
 
 ## `Describe` anidados
 
-Vamos a añadir más tests. Pero antes, hay que apuntar que la función `makeTest` y la instrución `for` deben ser agrupados juntos. No queremos `makeTest` en otros tests, solo se necesita en el `for`: su tarea común es comprobar cómo `pow` eleva dad una potencia concreta.
+Vamos a añadir más tests. Pero antes, hay que apuntar que la función `makeTest` y la instrución `for` deben ser agrupados juntos. No queremos `makeTest` en otros tests, solo se necesita en el `for`: su tarea común es comprobar cómo `pow` eleva a una potencia concreta.
 
 Agrupar tests se realiza con `describe`:
 
@@ -301,7 +301,7 @@ Normalmente, `beforeEach/afterEach` (`before/after`) son usados para realizar la
 
 ## Extender los spec
 
-La funcionalidad básica de `pow` está completa. La primera iteracción del desarrollo está hecha. Cuando acabemos de celebrar y beber champán -- sigamos adelante y mejorémosla.
+La funcionalidad básica de `pow` está completa. La primera iteración del desarrollo está hecha. Cuando acabemos de celebrar y beber champán -- sigamos adelante y mejorémosla.
 
 Como se dijo, la función `pow(x, n)` está dedicada a trabajar con valores enteros positivos `n`.
 
@@ -336,10 +336,9 @@ El resultado con los nuevos tests:
 El test recién creado falla, porque nuestra implementación no lo soporta. Así es como funciona la metodología BDD: primero escribimos un test que falle y luego realizamos la implementación para que pase.
 
 ```smart header="Otras comprobaciones"
-
 Por favor, ten en cuenta la comprobación `assert.isNaN`: ella comprueba que el valor es `NaN`.
 
-Hay otras comprobaciones en Chai también, por ejemplo:
+Hay otras comprobaciones en Chai también [Chai](http://chaijs.com), por ejemplo:
 
 - `assert.equal(value1, value2)` -- prueba la igualdad  `value1 == value2`.
 - `assert.strictEqual(value1, value2)` -- prueba la igualdad estricta `value1 === value2`.
@@ -386,16 +385,16 @@ El spec puede ser usado de tres formas:
 
 Con la especificación, podemos mejorar de forma segura, cambiar, incluso reescribir la función desde cero y estar seguros que seguirá funcionando.
 
-Esto es especialmente importante en proyectos largos cuando una función es usada en muchos sitios. Cuando cambiamos una función, no hay forma manual de comprobar si cada sitio dónde se usaba sigue funcionando correctamente.
+Esto es especialmente importante en proyectos largos cuando una función es usada en muchos sitios. Cuando cambiamos una función, no hay forma manual de comprobar si cada sitio donde se usaba sigue funcionando correctamente.
 
-Sin tests, la gente tiene dos maneras:
+Sin tests, la gente tiene dos opciones:
 
-1. Realizar el cambio, no importa nada más. Luegos los usuarios encontrán errores y deberán notificarlos. Si podemos abordarlo.
-2. La gente tiene miedo de cambiar funciones si el castigo por error es duro. Entonces el código envejecerá de forma descuidada con telarañas, nadie querrá meterse en él y eso no es bueno.
+1. Realizar el cambio, no importa nada más. Luego nuestros usuarios encontrán errores porque probablemente fallemos en encontrarlos.
+2. Si el castigo por errores es duro, la gente tendrá miedo de hacer cambios en las funciones. Entonces el código envejecerá, nadie querrá meterse en él y eso no es bueno para el desarrollo.
 
-**¡Las pruebas automáticas son lo contrario a eso!**
+**¡El test automatizado ayuda a evitar estos problemas!**
 
-Si el proyecto esta cubierto de pruebas, no tendremos ese problema. Podemos correr los tests y hacer multitud de comprabaciones en cuestión de segundos.
+Si el proyecto esta cubierto de pruebas, no tendremos ese problema. Podemos correr los tests y hacer multitud de comprobaciones en cuestión de segundos.
 
 **Además, un código bien probado tendrá una mejor arquitectura.**
 
@@ -403,10 +402,8 @@ Naturalmente, porque el código será más fácil de cambiar y mejorar. Pero no
 
 Al escribir tests, el código debe estar organizado de tal manera que cada función tenga un propósito claro y explícito, una entrada y una salida bien definida. Eso implica una buena arquitectura desde el principio.
 
-En la vida real a veces las cosas no son tan fáciles. A veces, es difícil escribir una especificación antes que el código, porque no esta claro aún cómo dee comportarse dicho código. Pero en general, escribir los tests hace el desarrollo más rápido y más estable.
-
-## ¿Qué viene ahora?
+En la vida real a veces no es tan fácil. A veces es difícil escribir una especificación antes que el código, porque no está claro aún cómo debe comportarse dicho código. Pero en general, escribir los tests hace el desarrollo más rápido y más estable.
 
-Al final en el tutorial encontrarás muchas tareas respaldadas con pruebas. Ahí tenemos más ejemplos prácticos de tests.
+En el tutorial encontrarás más adelante muchas tareas respaldadas con pruebas. Veremos más ejemplos prácticos de tests.
 
-Escribir tests requiere un buen conocimiento de JavaScript. Pero nosotros justo acabamos de empezar a aprenderlo. Así que para comenzar no es necesario que escribas tests, pero sí que seas capaz de leerlos y entenderlos, incluso ejemplos más complejos que aparecerán más adelante en este capítulo.
+Escribir tests requiere un buen conocimiento de JavaScript. Pero nosotros justo acabamos de empezar a aprenderlo. Así que para comenzar no es necesario que escribas tests, pero deberías ser capaz de leerlos incluso si son más compleos que en este capítulo.

From e7d3f06cbacc1594f41c59acc36784716f89eed0 Mon Sep 17 00:00:00 2001
From: joaquinelio <joaquinelio@gmail.com>
Date: Sun, 21 Jun 2020 12:07:20 -0300
Subject: [PATCH 3/3] Update solution.md

1-3-5-3 solution actualizado
---
 .../05-testing-mocha/3-pow-test-wrong/solution.md           | 6 ++++--
 1 file changed, 4 insertions(+), 2 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 6c0ecf179..138e1c751 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
@@ -4,9 +4,11 @@ Lo que tenemos aquí son en realidad 3 pruebas, pero presentadas como una sola f
 
 A veces es más fácil escribir de esta manera, pero si ocurre un error, es mucho menos obvio saber qué salió mal.
 
+Si un error ocurre en el medio de un flujo de ejecución complejo, tendremos que imaginar los datos en tal punto.  Tendremos, en realidad, que hacer un *debug del test*
+
 Sería mucho mejor dividir la prueba en múltiples bloques 'it' con entradas y salidas claramente escritas.
 
-Como ésto:
+Como esto:
 ```js
 describe("Eleva x a la potencia n", function() {
   it("5 elevado a 1 es igual a 5", function() {
@@ -23,7 +25,7 @@ describe("Eleva x a la potencia n", function() {
 });
 ```
 
-Reemplazamos el único `it` por un `describe` y agrupamos los bloques `it` dentro. Ahora si algo sale mal, podemos ver claramente que dato fue.
+Reemplazamos el único `it` por un `describe` y agrupamos los bloques `it` dentro. Ahora si algo sale mal, podemos ver claramente qué dato fue.
 
 Además podemos aislar un único test y ejecutarlo individualmente escribiendo `it.only` en lugar de `it`: