From d1d3e10d255b5babe30010a25b13b964b7aeffd4 Mon Sep 17 00:00:00 2001 From: Kyle Martin Date: Sat, 3 Aug 2019 10:58:08 +1200 Subject: [PATCH 1/3] Update --- all-contributors.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/all-contributors.md b/all-contributors.md index bce37d593..87244bfbf 100644 --- a/all-contributors.md +++ b/all-contributors.md @@ -1,3 +1,5 @@ - +## Test + + From 38e98f1a966cce6935e9cbaddb0f769a0d29640e Mon Sep 17 00:00:00 2001 From: Ziyaddin Sadigov Date: Sun, 4 Aug 2019 13:24:28 +0400 Subject: [PATCH 2/3] update istanbul/nyc links --- README.brazilian-portuguese.md | 2 +- README.chinese.md | 2 +- README.korean.md | 2 +- README.md | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/README.brazilian-portuguese.md b/README.brazilian-portuguese.md index 5bc771805..5f4462d68 100644 --- a/README.brazilian-portuguese.md +++ b/README.brazilian-portuguese.md @@ -489,7 +489,7 @@ Todas as declarações acima false se feitas com `===`. ## ![✔] 4.7 Verifique a cobertura de seu teste, isso te ajuda a identificar padrões incorretos de teste -**TL;DR:** Ferramentas de cobertura de código como [Istanbul/NYC ](https://github.com/gotwarlost/istanbul), são ótimas por 3 motivos: elas são gratuitas (nenhum esforço é necessário para beneficiar esses relatórios), elas ajuda a identificar diminuição na cobertura de testes, e por último mas não menos importante, ela destacam a incompatibilidade de testes: olhando relatórios coloridos de cobertura de código, você pode notar, por exemplo, áreas de código que nunca são testadas como cláusulas catch (o que significa que os testes só invocam os caminhos felizes e não como o aplicativo se comporta em erros). Configure-o para falhas se a cobertura estiver abaixo de um certo limite. +**TL;DR:** Ferramentas de cobertura de código como [Istanbul](https://github.com/istanbuljs/istanbuljs)/[NYC](https://github.com/istanbuljs/nyc), são ótimas por 3 motivos: elas são gratuitas (nenhum esforço é necessário para beneficiar esses relatórios), elas ajuda a identificar diminuição na cobertura de testes, e por último mas não menos importante, ela destacam a incompatibilidade de testes: olhando relatórios coloridos de cobertura de código, você pode notar, por exemplo, áreas de código que nunca são testadas como cláusulas catch (o que significa que os testes só invocam os caminhos felizes e não como o aplicativo se comporta em erros). Configure-o para falhas se a cobertura estiver abaixo de um certo limite. **Caso contrário:** Não haverá nenhuma métrica automática informando quando uma grande parte de seu código não é coberta pelo teste. diff --git a/README.chinese.md b/README.chinese.md index 10d67985e..b83f46066 100644 --- a/README.chinese.md +++ b/README.chinese.md @@ -436,7 +436,7 @@ null == undefined // true ## ![✔] 4.6 检查测试覆盖率，它有助于识别错误的测试模式 -**TL;DR:** 代码覆盖工具比如[Istanbul/NYC ](https://github.com/gotwarlost/istanbul)，很好用有3个原因：它是免费的（获得这份报告不需要任何开销），它有助于确定测试覆盖率降低的部分，以及最后但非最不重要的是它指出了测试中的不匹配：通过查看颜色标记的代码覆盖报告您可以注意到，例如，从来不会被测到的代码片段像catch语句（即测试只是调用正确的路径，而不调用应用程序发生错误时的行为）。如果覆盖率低于某个阈值，则将其设置为失败的构建。 +**TL;DR:** 代码覆盖工具比如 [Istanbul](https://github.com/istanbuljs/istanbuljs)/[NYC](https://github.com/istanbuljs/nyc)，很好用有3个原因：它是免费的（获得这份报告不需要任何开销），它有助于确定测试覆盖率降低的部分，以及最后但非最不重要的是它指出了测试中的不匹配：通过查看颜色标记的代码覆盖报告您可以注意到，例如，从来不会被测到的代码片段像catch语句（即测试只是调用正确的路径，而不调用应用程序发生错误时的行为）。如果覆盖率低于某个阈值，则将其设置为失败的构建。 **否则:** 当你的大部分代码没有被测试覆盖时，就不会有任何自动化的度量指标告诉你了。 diff --git a/README.korean.md b/README.korean.md index 8580d7b30..543f56f72 100644 --- a/README.korean.md +++ b/README.korean.md @@ -429,7 +429,7 @@ null == undefined // true ## ![✔] 4.6 Check your test coverage, it helps to identify wrong test patterns -**핵심요약:** Code coverage tools like [Istanbul/NYC ](https://github.com/gotwarlost/istanbul)are great for 3 reasons: it comes for free (no effort is required to benefit this reports), it helps to identify a decrease in testing coverage, and last but not least it highlights testing mismatches: by looking at colored code coverage reports you may notice, for example, code areas that are never tested like catch clauses (meaning that tests only invoke the happy paths and not how the app behaves on errors). Set it to fail builds if the coverage falls under a certain threshold +**핵심요약:** Code coverage tools like [Istanbul](https://github.com/istanbuljs/istanbuljs)/[NYC](https://github.com/istanbuljs/nyc) are great for 3 reasons: it comes for free (no effort is required to benefit this reports), it helps to identify a decrease in testing coverage, and last but not least it highlights testing mismatches: by looking at colored code coverage reports you may notice, for example, code areas that are never tested like catch clauses (meaning that tests only invoke the happy paths and not how the app behaves on errors). Set it to fail builds if the coverage falls under a certain threshold **그렇게 하지 않을 경우:** There won't be any automated metric telling you when a large portion of your code is not covered by testing diff --git a/README.md b/README.md index 031a19333..3618b5d9d 100644 --- a/README.md +++ b/README.md @@ -501,7 +501,7 @@ All statements above will return false if used with `===` ## ![✔] 4.8 Check your test coverage, it helps to identify wrong test patterns -**TL;DR:** Code coverage tools like [Istanbul/NYC ](https://github.com/gotwarlost/istanbul)are great for 3 reasons: it comes for free (no effort is required to benefit this reports), it helps to identify a decrease in testing coverage, and last but not least it highlights testing mismatches: by looking at colored code coverage reports you may notice, for example, code areas that are never tested like catch clauses (meaning that tests only invoke the happy paths and not how the app behaves on errors). Set it to fail builds if the coverage falls under a certain threshold +**TL;DR:** Code coverage tools like [Istanbul](https://github.com/istanbuljs/istanbuljs)/[NYC](https://github.com/istanbuljs/nyc) are great for 3 reasons: it comes for free (no effort is required to benefit this reports), it helps to identify a decrease in testing coverage, and last but not least it highlights testing mismatches: by looking at colored code coverage reports you may notice, for example, code areas that are never tested like catch clauses (meaning that tests only invoke the happy paths and not how the app behaves on errors). Set it to fail builds if the coverage falls under a certain threshold **Otherwise:** There won't be any automated metric telling you when a large portion of your code is not covered by testing From 0977bec735578e2504eafe9790e3551a6def7863 Mon Sep 17 00:00:00 2001 From: Alexander Ivanov Date: Mon, 5 Aug 2019 08:41:51 +0300 Subject: [PATCH 3/3] Reflection of #452 --- README.russian.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.russian.md b/README.russian.md index a2c74c4f0..7f02b6aee 100644 --- a/README.russian.md +++ b/README.russian.md @@ -501,7 +501,7 @@ null == undefined // true ## ![✔] 4.8 Проверьте ваше покрытие тестов, он помогает определить неправильные тестовые шаблоны -**TL;DR:** Инструменты покрытия кода тестами, такие как [Istanbul/NYC](https://github.com/gotwarlost/istanbul) хороши по 3 причинам: они предоставляются бесплатно (никаких усилий не требуется, чтобы воспользоваться этими отчетами) это помогает выявить уменьшение охвата тестирования и, наконец, что не менее важно, подчеркивает несоответствия тестирования: просматривая цветные отчеты о покрытии кода, вы можете заметить, например, области кода, которые никогда не тестируются, как предложения catch (то есть тесты вызывают только счастливые пути, а не то, как приложение ведет себя на ошибках). Установите его на сбой сборки, если охват падает ниже определенного порога. +**TL;DR:** Инструменты покрытия кода тестами, такие как [Istanbul](https://github.com/istanbuljs/istanbuljs)/[NYC](https://github.com/istanbuljs/nyc) хороши по 3 причинам: они предоставляются бесплатно (никаких усилий не требуется, чтобы воспользоваться этими отчетами) это помогает выявить уменьшение охвата тестирования и, наконец, что не менее важно, подчеркивает несоответствия тестирования: просматривая цветные отчеты о покрытии кода, вы можете заметить, например, области кода, которые никогда не тестируются, как предложения catch (то есть тесты вызывают только счастливые пути, а не то, как приложение ведет себя на ошибках). Установите его на сбой сборки, если охват падает ниже определенного порога. **Иначе:** Там не будет никакой автоматической метрики, сообщающей вам, когда большая часть вашего кода не покрыта тестированием.