Merge branch 'master' into smonn/typo-fixes

Author: goldbergyoni

.all-contributorsrc

@@ -360,10 +360,101 @@
         "translation",
         "code"
       ]
+    },
+    {
+      "login": "TREER00T",
+      "name": "Ali Azmoodeh",
+      "avatar_url": "https://avatars.githubusercontent.com/u/76606342?v=4",
+      "profile": "https://github.com/TREER00T",
+      "contributions": [
+        "content"
+      ]
+    },
+    {
+      "login": "Saimon398",
+      "name": "Alex Popov",
+      "avatar_url": "https://avatars.githubusercontent.com/u/71539667?v=4",
+      "profile": "https://github.com/Saimon398",
+      "contributions": [
+        "content"
+      ]
+    },
+    {
+      "login": "Shramkoweb",
+      "name": "Serhii Shramko",
+      "avatar_url": "https://avatars.githubusercontent.com/u/42001531?v=4",
+      "profile": "http://shramko.dev",
+      "contributions": [
+        "content"
+      ]
+    },
+    {
+      "login": "yugoccp",
+      "name": "Yugo Sakamoto",
+      "avatar_url": "https://avatars.githubusercontent.com/u/1724114?v=4",
+      "profile": "https://github.com/yugoccp",
+      "contributions": [
+        "content"
+      ]
+    },
+    {
+      "login": "Fdawgs",
+      "name": "Frazer Smith",
+      "avatar_url": "https://avatars.githubusercontent.com/u/43814140?v=4",
+      "profile": "https://yeovilhospital.co.uk/",
+      "contributions": [
+        "content"
+      ]
+    },
+    {
+      "login": "wralith",
+      "name": "Wralith",
+      "avatar_url": "https://avatars.githubusercontent.com/u/75392169?v=4",
+      "profile": "https://github.com/wralith",
+      "contributions": [
+        "content"
+      ]
+    },
+    {
+      "login": "saseungmin",
+      "name": "Harang",
+      "avatar_url": "https://avatars.githubusercontent.com/u/60910665?v=4",
+      "profile": "https://haranglog.tistory.com",
+      "contributions": [
+        "content"
+      ]
+    },
+    {
+      "login": "rcanelav",
+      "name": "rcanelav",
+      "avatar_url": "https://avatars.githubusercontent.com/u/64812826?v=4",
+      "profile": "https://github.com/rcanelav",
+      "contributions": [
+        "content"
+      ]
+    },
+    {
+      "login": "drewrwilson",
+      "name": "Drew Wilson",
+      "avatar_url": "https://avatars.githubusercontent.com/u/4324656?v=4",
+      "profile": "https://github.com/drewrwilson",
+      "contributions": [
+        "content"
+      ]
+    },
+    {
+      "login": "XtLee",
+      "name": "XtLee",
+      "avatar_url": "https://avatars.githubusercontent.com/u/30145777?v=4",
+      "profile": "https://github.com/XtLee",
+      "contributions": [
+        "content"
+      ]
     }
   ],
   "projectName": "javascript-testing-best-practices",
   "projectOwner": "goldbergyoni",
   "repoType": "github",
-  "repoHost": "https://github.com"
+  "repoHost": "https://github.com",
+  "commitConvention": "angular"
 }

assets/header.pptx

@@ -35,6 +35,7 @@ Empieza por comprender las técnicas de testing ubicuas que son la base de cualq
 - 🇵🇱[Polaco](readme-pl.md) - cortesía de [Michal Biesiada](https://github.com/mbiesiad)
 - 🇪🇸[Español](readme-es.md) - cortesía de [Miguel G. Sanguino](https://github.com/sanguino)
 - 🇧🇷[Portugués-BR](readme-pt-br.md) - cortesía de [Iago Angelim Costa Cavalcante](https://github.com/iagocavalcante), [Douglas Mariano Valero](https://github.com/DouglasMV) y [koooge](https://github.com/koooge)
+- 🇺🇦[Ukrainian](readme-ua.md) - cortesía de [Serhii Shramko](https://github.com/Shramkoweb)
 - ¿Quieres traducir a tu propio lenguaje? por favor abre una issue 💜
 
 <br/><br/>
@@ -893,7 +894,7 @@ Crédito: <a href="https://github.com/TheHollidayInn" data-href="https://github.
 
 ## ⚪ ️ 2.6 Comprueba tu predisposición al caos relacionado con Node
 
-:white_check_mark: **Haz:** Extrañamente, la mayoría de los test de software son acerca de lógica y datos, pero los errores más grabes (y que son muy difíciles de resolver) son problemas de infraestructura. Por ejemplo, ¿alguna vez has testeado que pasa cuando se sobrecarga la memoria? ¿o cuando el servidor/proceso muere? ¿o tu sistema de monitorización es capaz de darse cuenta cuando la API es un 50% más lenta de lo normal? Para probar y evitar este tipo de problemas — [Chaos engineering](https://principlesofchaos.org/) fue creado por Netflix. Su objetivo es proporcionar conciencia, frameworks, y herramientas para testear la resiliencia de nuestras aplicaciones en problemas caóticos. Por ejemplo, una de las herramientas más conocidas [the chaos monkey](https://github.com/Netflix/chaosmonkey), mata servidores de forma aleatoria para comprobar si nuestro servicio aun puede dar servicio a los usuarios y asegurar que no depende de un solo servidor (hay también una versión para kubernetes, [kube-monkey](https://github.com/asobti/kube-monkey), que mata pods en vez de servidores. Todas estas herramientas funcionan a nivel de hosting/plataforma, pero ¿qué pasa si deseas probar y generar caos a nivel Node puramente como comprobar como tu proceso Node hace frente a errores no controlados, o a rejects de promesas no capturados, o sobrecarga de la memoria de v8 por encima del máximo de 1.7GB o si la UX sigue siendo buena si se satura el event loop? Para todo esto he escrito [node-chaos](https://github.com/i0natan/node-chaos-monkey) (alpha) que proporciona todo tipo de formas de crear el caos en Node
+:white_check_mark: **Haz:** Extrañamente, la mayoría de los test de software son acerca de lógica y datos, pero los errores más graves (y que son muy difíciles de resolver) son problemas de infraestructura. Por ejemplo, ¿alguna vez has testeado que pasa cuando se sobrecarga la memoria? ¿o cuando el servidor/proceso muere? ¿o tu sistema de monitorización es capaz de darse cuenta cuando la API es un 50% más lenta de lo normal? Para probar y evitar este tipo de problemas — [Chaos engineering](https://principlesofchaos.org/) fue creado por Netflix. Su objetivo es proporcionar conciencia, frameworks, y herramientas para testear la resiliencia de nuestras aplicaciones en problemas caóticos. Por ejemplo, una de las herramientas más conocidas [the chaos monkey](https://github.com/Netflix/chaosmonkey), mata servidores de forma aleatoria para comprobar si nuestro servicio aun puede dar servicio a los usuarios y asegurar que no depende de un solo servidor (hay también una versión para kubernetes, [kube-monkey](https://github.com/asobti/kube-monkey), que mata pods en vez de servidores. Todas estas herramientas funcionan a nivel de hosting/plataforma, pero ¿qué pasa si deseas probar y generar caos a nivel Node puramente como comprobar como tu proceso Node hace frente a errores no controlados, o a rejects de promesas no capturados, o sobrecarga de la memoria de v8 por encima del máximo de 1.7GB o si la UX sigue siendo buena si se satura el event loop? Para todo esto he escrito [node-chaos](https://github.com/i0natan/node-chaos-monkey) (alpha) que proporciona todo tipo de formas de crear el caos en Node
 <br/>
 
 ❌ **De lo contrario:** No hay escapatoria, la ley de Murphy afectará a producción sin piedad

assets/zh-CN/bp-1-3-parts.jpg

@@ -35,6 +35,7 @@ Commence par comprendre les pratiques de tests omniprésentes qui sont à la bas
 - 🇵🇱[Polonais](readme-pl.md) - Traduit par [Michal Biesiada](https://github.com/mbiesiad)
 - 🇪🇸[Espagnol](readme-es.md) - Traduit par [Miguel G. Sanguino](https://github.com/sanguino)
 - 🇧🇷[Portugais brésilien](readme-pt-br.md) - Traduit par [Iago Angelim Costa Cavalcante](https://github.com/iagocavalcante) , [Douglas Mariano Valero](https://github.com/DouglasMV) et [koooge](https://github.com/koooge)
+- 🇺🇦[Ukrainian](readme-ua.md) - Traduit par [Serhii Shramko](https://github.com/Shramkoweb)
 - Envie de traduire dans ta propre langue ? Ouvres une issue 💜
 
 <br/><br/>
@@ -1963,4 +1964,4 @@ Merci à ces merveilleuses personnes qui ont contribué à ce repo!
 <!-- markdownlint-restore -->
 <!-- prettier-ignore-end -->
 
-<!-- ALL-CONTRIBUTORS-LIST:END -->
+<!-- ALL-CONTRIBUTORS-LIST:END -->