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..fc80a404a 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,49 @@
-The test demonstrates one of the temptations a developer meets when writing tests.
+O teste, demonstra uma das tentações que um desenvolvedor pode ter ao escrever testes.
-What we have here is actually 3 tests, but layed out as a single function with 3 asserts.
+O que na verdade temos aqui são 3 testes, mas estruturados utilizando uma única função com 3 asserts.
-Sometimes it's easier to write this way, but if an error occurs, it's much less obvious what went wrong.
+Por vezes, é mais fácil escrever desta forma, mas se algum erro ocorrer, é muito menos óbvio o que houve de errado.
-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*.
+Se um erro ocorrer dentro de uma execução de um fluxo complexo, então teremos de adivinhar quais os dados nessa altura. Na verdade, temos de efetuar uma *depuração de erros ao teste* (*debug the test*).
-It would be much better to break the test into multiple `it` blocks with clearly written inputs and outputs.
+Seria muito melhor particionar (*break*) o teste em múltiplos blocos `it` com entrada de dados (*input*) e saída de dados (*output*) claramente escritas.
-Like this:
+Desta forma:
```js
-describe("Raises x to power n", function() {
- it("5 in the power of 1 equals 5", function() {
+describe("Eleva x à potência de n", function() {
+ it("5 elevado a 1 é igual a 5", function() {
assert.equal(pow(5, 1), 5);
});
- it("5 in the power of 2 equals 25", function() {
+ it("5 elevado a of 2 é igual a 25", function() {
assert.equal(pow(5, 2), 25);
});
- it("5 in the power of 3 equals 125", function() {
+ it("5 elevado a of 3 é 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.
+Nós substituimos um único `it` por `describe` e um grupo de blocos `it`. Então, se algo falhasse, poderíamos claramente ver que dados existiriam.
-Also we can isolate a single test and run it in standalone mode by writing `it.only` instead of `it`:
+Também podemos isolar um único teste, e executá-lo no modo *standalone* escrevendo `it.only` em vez de `it`:
```js
-describe("Raises x to power n", function() {
- it("5 in the power of 1 equals 5", function() {
+describe("Eleva x à potência de n", function() {
+ it("5 elevado a 1 é 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() {
+ // O Mocha apenas correrá neste bloco
+ it.only("5 elevado a 2 é 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 é 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..bcd7d8773 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?
+# O que há de errado no teste?
-What's wrong in the test of `pow` below?
+O que há de errado no teste de `pow` abaixo?
```js
-it("Raises x to the power n", function() {
+it("Eleva x à potência de 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. Sintáticamente, o teste está correto e passa.
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..f5ee73e13 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,148 @@
-# Automated testing with mocha
+# Teste automatizado com Mocha
-Automated testing will be used in further tasks.
+Teste automatizado será empregue nas próximas tarefas.
-It's actually a part of the "educational minimum" of a developer.
+É, na verdade, uma parte da "educação mínima" de um desenvolvedor.
-## Why we need tests?
+## Porque precisamos de testes?
-When we write a function, we can usually imagine what it should do: which parameters give which results.
+Quando escrevemos uma função, podemos geralmente imaginar como ela deverá ser: quais parâmetros darão quais resultados.
-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 o desenvolvimento, podemos analizar a função executando-a, e comparando o resultado obtido com o esperado. Por exemplo, podemos fazê-lo na consola.
-If something is wrong -- then we fix the code, run again, check the result -- and so on till it works.
+Se alguma coisa estiver errada -- podemos corrigir o código, executá-lo de novo, verificar o resultado -- e assim sucessivamente, até que funcione.
-But such manual "re-runs" are imperfect.
+Mas, tais "re-execuções" manuais são imperfeitas.
-**When testing a code by manual re-runs, it's easy to miss something.**
+**Quando se testa um código com re-execuções manuais, é fácil falhar em alguma coisa.**
-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 exemplo, estamos a criar uma função `f`. Escrevemos algum código, e ao testar: `f(1)` funciona, mas `f(2)` não. Corrigimos o código e agora `f(2)` funciona. Parece completa? Mas nos esquecemos de re-testar `f(1)`. Que pode fornecer um erro.
-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.
+É muito típico. Quando desenvolvemos algo, mantemos uma quantidade de casos possíveis em mente. Mas, é difícil esperar que um programador os verifique todos manualmente após cada alteração. Assim, torna-se fácil corrigir uma coisa e danificar outra.
-**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.**
+**Teste automatizado significa que testes são escritos em separado, adicionalmente ao código. Eles podem ser fácilmente executados e verificar todos os principais casos esperados.**
-## Behavior Driven Development (BDD)
+## Desenvolvimento Orientado por Comportamento (*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 examinar uma técnica conhecida por [Behavior Driven Development](http://en.wikipedia.org/wiki/Behavior-driven_development) (Desenvolvimento Orientado por Comportamento) ou, abreviadamente, *BDD*. Essa prática é empregue em muitos projetos. *BDD* não é apenas usado em testes. Porém, existe para além deles.
-**BDD is three things in one: tests AND documentation AND examples.**
+**_BDD_ são três coisas em uma: testes E documentação E exemplos.**
-Enough words. Let's see the example.
+Basta de palavras. Vejamos um exemplo.
-## Development of "pow": the spec
+## Desenvolvimento de "*pow*": a especificação (*spec*)
-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 construir a função `pow(x, n)` que eleva `x` a uma potência inteira `n`. Assuimos 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.
+Essa tarefa apenas é um exemplo: existe o operador `**` em JavaScript que a faz mas, aqui nós nos concentramos no fluxo de desenvolvimento, que pode também ser aplicado a tarefas mais complexas.
-Before creating the code of `pow`, we can imagine what the function should do and describe it.
+Antes de criar o código de `pow`, podemos imaginar o que a função deveria fazer e o descrever.
-Such description is called a *specification* or, in short, a spec, and looks like this:
+Tal descrição, é chamada de uma *especificação* (*specification*), ou abreviadamente uma *spec*, e tem este aspeto:
```js
describe("pow", function() {
- it("raises to n-th power", function() {
+ it("eleva à n-ésima potência", function() {
assert.equal(pow(2, 3), 8);
});
});
```
-A spec has three main building blocks that you can see above:
+Uma *spec*, possui três principais blocos, que pode observar acima:
`describe("title", function() { ... })`
-: What functionality we're describing. Uses to group "workers" -- the `it` blocks. In our case we're describing the function `pow`.
+
Que funcionalidade estamos a descrever. É utilizado para agrupar "*workers*" -- os blocos `it`. No nosso caso, estamos a descrever a função `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.
+
No título de `it` nós, *numa forma humanamente-legível*, descrevemos o caso prático (*use case*) específico, e no segundo argumento está uma função que o testa.
`assert.equal(value1, value2)`
-: The code inside `it` block, if the implementation is correct, should execute without errors.
+
O código dentro do bloco `it`, se a implementação estiver correta, deveria executar sem erros.
- 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`.
+ Funções `assert.*`, são empregues para testar se `pow` funciona como esperado. Exatamente aqui usamos uma delas -- `assert.equal`, que compara argumentos e produz um erro se não forem iguais. Aqui, ela verifica se o resultado de `pow(2, 3)` é igual a `8`.
- There are other types of comparisons and checks that we'll see further.
+ Existem outros tipos de comparações e verificações, que veremos mais adiante.
-## The development flow
+## O fluxo de desenvolvimento
-The flow of development usually looks like this:
+O fluxo de desenvolvimento, geralmente assemelha-se a este:
-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. Uma *spec* inicial é escrita, com testes para as mais básicas funcionalidades.
+2. Uma implementação inicial é criada.
+3. Para verificar se funciona, nós corremos a *framework* de testes [Mocha](http://mochajs.org/) (mais detalhes em breve), que executa a *spec*. Erros são apresentados. Fazemos correções até que tudo funcione.
+4. Agora, temos uma implementação inicial a funcionar com testes.
+5. Adicionamos mais casos práticos (*use cases*) à *spec*, provavelmente ainda não suportados pelas implementações. Testes começam a falhar.
+6. Retornamos ao 3, atualizamos a implementação até que os testes não produzam erros.
+7. Repetimos os passos 3-6 até a funcionalidade estar pronta.
-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.
+Assim, o desenvolvimento é *iterativo*. Escrevemos uma *spec*, a implementamos, certificamo-nos de que os testes passam, depois escrevemos mais testes, certificamo-nos de que eles funcionam, etc. No final, temos ambos, uma implementação a funcionar e testes para ela.
-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).
+No nosso caso, o primeiro passo está completo: temos uma *spec* inicial para `pow`. Assim, façamos uma implementação. Mas, antes façamos uma execução "zero" da *spec*, apenas para ver se os testes estão a funcionar (eles todos irão falhar).
-## The spec in action
+## A *spec* em ação
-Here in the tutorial we'll be using the following JavaScript libraries for tests:
+Aqui, no tutorial, iremos utilizar para testes as seguintes bibliotecas de JavaScript (*JavaScript libraries*):
-- [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/) -- a *framework* nuclear: ela fornece funções de teste comuns, incluindo `describe` e `it`, e a principal função que executa os testes.
+- [Chai](http://chaijs.com) -- uma biblioteca (*library*) com muitas *assertions*. Ela permite o uso de muitas diferentes *assertions*, mas por ora apenas precisamos de `assert.equal`.
+- [Sinon](http://sinonjs.org/) -- uma biblioteca para espiar sobre funções, simular funções incorporadas à linguagem (*built-in functions*) e mais; precisaremos dela muito mais tarde.
-These libraries are suitable for both in-browser and server-side testing. Here we'll consider the browser variant.
+Estas bibliotecas, são apropriadas tanto para testes de código a executar pelo navegador (*browser*) como pelo servidor (*server-side*). Aqui, iremos considerar a variante para o navegador.
-The full HTML page with these frameworks and `pow` spec:
+A página completa em HTML com estas *frameworks*, e a *spec* `pow`:
-```html src="index.html"
+```html
+ src="index.html"
```
-The page can be divided into five parts:
+ A página, pode ser dividida em cinco partes:
-1. The `