es-testing-testing-environments #277

Gerson4G · 2019-08-25T15:05:12Z

Traducción de la seccion "Testing Environments" al español.
Ayuda solicitada en #273
Atento a las recomendaciones @Darking360 @carburo

Gerson4G · 2019-08-25T15:06:03Z

content/docs/testing-environments.md


-In most cases, jsdom behaves like a regular browser would, but doesn't have features like [layout and navigation](https://github.com/jsdom/jsdom#unimplemented-parts-of-the-web-platform). This is still useful for most web-based component tests, since it runs quicker than having to start up a browser for each test. It also runs in the same process as your tests, so you can write code to examine and assert on the rendered DOM.


No estoy seguro como traducir layout. Hay dos coincidencias de la palabra en el documento. Atento a las sugerencias.

Creo que en este caso está bien dejarlo como layout - qué opinan @carburo @Darking360 ?

Sí, puede ser, creo que muchas veces se usa el término en inglés a falta de una traducción lo suficientemente satisfactoria. Quizá podríamos luego evaluar las diferentes alternativas y a partir de la decisión ponerlo en la lista de traducciones comunes para futuras referencias.

De acuerdo en dejarlo como layout, las traducciones literales a la palabra no quedan bien dentro de este contexto, lo podriamos dejar asi y luego revisar bien el glosario y actulizarlo como menciona @carburo 🚀

Gerson4G · 2019-08-25T15:07:25Z

content/docs/testing-environments.md


-This is especially useful for data fetching. It is usually preferable to use "fake" data for tests to avoid the slowness and flakiness due to fetching from real API endpoints [<small>(example)</small>](/docs/testing-recipes.html#data-fetching). This helps make the tests predictable. Libraries like [Jest](https://jestjs.io/) and [sinon](https://sinonjs.org/), among others, support mocked functions. For end-to-end tests, mocking network can be more difficult, but you might also want to test the real API endpoints in them anyway.


Decidi por dejar API Endpoints en su idioma original. En otro articulo observe que se traducia a remote endpoint -> punto final remoto y en mi opinión no se ve bien dentro del contexto.

Yep, de acuerdo! Gracias por aclarar tu decisión!

Gerson4G · 2019-08-25T15:08:25Z

content/docs/testing-environments.md


-In this scenario, you would use a framework like [Cypress](https://www.cypress.io/) or a library like [puppeteer](https://github.com/GoogleChrome/puppeteer) so you can navigate between multiple routes and assert on side effects not just in the browser, but potentially on the backend as well.


backend fue otra traducción de la que no estoy seguro. Me parece que también deberia mantenerse la palabra. Atento igualmente.

@Gerson4G 👍

netlify · 2019-08-25T15:10:40Z

Deploy preview for es-reactjs ready!

Built with commit 2fb5c4a

https://deploy-preview-277--es-reactjs.netlify.com

alejandronanez

Hey @Gerson4G, gracias por tu aporte, bienvenido al proyecto!

Me parece que este PR está bien, pero dejo abierta la pregunta sobre cambiar Biblioteca por Librería, además de layout.

Si @carburo o @Darking360 les parece 👍 como están las cosas podemos proceder con el merge!

Muchas gracias nuevamente!!!!!!

alejandronanez · 2019-08-27T13:17:02Z

content/docs/testing-environments.md


-### Test runners {#test-runners}
+### Bibliotecas de ejecución de pruebas {#test-runners}


Hola @Gerson4G! Qué tal te suena Librerías en vez de Bibliotecas?

También puede ser, pero entonces se debería buscar una estandarización para este tipo de palabras (Test Runners) ya que elegí "Bibliotecas" debido a la traducción realizada en esta página donde Jest is a JavaScript test runner -> Jest Es una biblioteca de JavaScript para ejecución de pruebas 🤔 @carburo @Darking360.
Librería sí suena mejor para mí, no se si quizás cambiar acá y crear el PR para los otros lados de la documentación donde se le haga referencia aTest Runner que lleve Biblioteca?

De hecho, en la lista de traducciones comunes está traducido como biblioteca y ha sido lo más común en otras traducciones en aras de mantener la consistencia. Para ser honesto, prefiero biblioteca al calco semántico, pero no me importaría que revisaramos esa decisión. En cualquier caso en el artículo se usa indistintamente biblioteca y librería y sí creo que al menos dentro del artículo se mantenga la consistencia y se elija solo uno u otro término.

En este caso tambien me guié de la lista de traducciones comunes, en su momento muy al inicio de las traducciones se acordó usar Biblioteca por el contexto si mal no recuerdo, eso o se parecía mucho al error de la traducción literal de support que es soportar pero en realidad traduce a compatible por ejemplo, aunque tambien lo podríamos revisar, de una u otra forma como menciona @carburo no esta mal, aunque debemos mantener la consistencia, si vamos al caso, por ahora se seguiría utilizando Biblioteca 👍

alejandronanez · 2019-08-27T13:17:49Z

content/docs/testing-environments.md


-In most cases, jsdom behaves like a regular browser would, but doesn't have features like [layout and navigation](https://github.com/jsdom/jsdom#unimplemented-parts-of-the-web-platform). This is still useful for most web-based component tests, since it runs quicker than having to start up a browser for each test. It also runs in the same process as your tests, so you can write code to examine and assert on the rendered DOM.


Creo que en este caso está bien dejarlo como layout - qué opinan @carburo @Darking360 ?

alejandronanez · 2019-08-27T13:18:59Z

content/docs/testing-environments.md


-This is especially useful for data fetching. It is usually preferable to use "fake" data for tests to avoid the slowness and flakiness due to fetching from real API endpoints [<small>(example)</small>](/docs/testing-recipes.html#data-fetching). This helps make the tests predictable. Libraries like [Jest](https://jestjs.io/) and [sinon](https://sinonjs.org/), among others, support mocked functions. For end-to-end tests, mocking network can be more difficult, but you might also want to test the real API endpoints in them anyway.


Yep, de acuerdo! Gracias por aclarar tu decisión!

alejandronanez · 2019-08-27T13:19:37Z

content/docs/testing-environments.md


-In this scenario, you would use a framework like [Cypress](https://www.cypress.io/) or a library like [puppeteer](https://github.com/GoogleChrome/puppeteer) so you can navigate between multiple routes and assert on side effects not just in the browser, but potentially on the backend as well.


@Gerson4G 👍

carburo

Muchísimas gracias @Gerson4G por la traducción. Como ya estaba haciendo una reseña de este artículo sumo a la de @alejandronanez algunas sugerencias, sobre todo algunas erratas que encontré y comenté sobre la cuestión de «bibliotecas» y «librerías». También noto que olvidaste traducir el título de la publicación.

content/docs/testing-environments.md

carburo · 2019-08-28T01:00:29Z

content/docs/testing-environments.md


-### Test runners {#test-runners}
+### Bibliotecas de ejecución de pruebas {#test-runners}


De hecho, en la lista de traducciones comunes está traducido como biblioteca y ha sido lo más común en otras traducciones en aras de mantener la consistencia. Para ser honesto, prefiero biblioteca al calco semántico, pero no me importaría que revisaramos esa decisión. En cualquier caso en el artículo se usa indistintamente biblioteca y librería y sí creo que al menos dentro del artículo se mantenga la consistencia y se elija solo uno u otro término.

content/docs/testing-environments.md

carburo · 2019-08-28T01:08:39Z

content/docs/testing-environments.md


-In most cases, jsdom behaves like a regular browser would, but doesn't have features like [layout and navigation](https://github.com/jsdom/jsdom#unimplemented-parts-of-the-web-platform). This is still useful for most web-based component tests, since it runs quicker than having to start up a browser for each test. It also runs in the same process as your tests, so you can write code to examine and assert on the rendered DOM.


Sí, puede ser, creo que muchas veces se usa el término en inglés a falta de una traducción lo suficientemente satisfactoria. Quizá podríamos luego evaluar las diferentes alternativas y a partir de la decisión ponerlo en la lista de traducciones comunes para futuras referencias.

carburo · 2019-08-28T01:11:35Z

content/docs/testing-environments.md


-In this scenario, you would use a framework like [Cypress](https://www.cypress.io/) or a library like [puppeteer](https://github.com/GoogleChrome/puppeteer) so you can navigate between multiple routes and assert on side effects not just in the browser, but potentially on the backend as well.
+En este escenario, podrías usar un framework como [Cypress](https://www.cypress.io/) o una libreria como [puppeteer](https://github.com/GoogleChrome/puppeteer) de forma que puedas navegar entre diferentes rutas y comprobar los efectos no solo del navegador si no potencialmente del backend también.


Suggested change

En este escenario, podrías usar un framework como [Cypress](https://www.cypress.io/) o una libreria como [puppeteer](https://github.com/GoogleChrome/puppeteer) de forma que puedas navegar entre diferentes rutas y comprobar los efectos no solo del navegador si no potencialmente del backend también.

En este escenario, podrías usar un framework como [Cypress](https://www.cypress.io/) o una librería como [puppeteer](https://github.com/GoogleChrome/puppeteer) de forma que puedas navegar entre diferentes rutas y comprobar los efectos no solo del navegador si no potencialmente del backend también.

Aqui cambiaría libreria por biblioteca como se hablo anteriormente 😅

Co-Authored-By: Rainer Martínez Fraga <[email protected]>

Darking360

@Gerson4G Se ve super, solamente puse los cambios de libreria por biblioteca para mantener la consistencia en todas las traducciones que hay por ahora 🚀 Despues de eso creo que estariamos listos.

CC @alejandronanez @carburo 💪

Darking360 · 2019-08-28T22:23:26Z

content/docs/testing-environments.md

- Libraries like [mocha](https://mochajs.org/#running-mocha-in-the-browser) work well in real browser environments, and could help for tests that explicitly need it.
- End-to-end tests are used for testing longer flows across multiple pages, and require a [different setup](#end-to-end-tests-aka-e2e-tests).
+- Jest es altamente compatible con proyectos de React, soportando características como [modulos simulados](#mocking-modules) y [temporizadores](#mocking-timers), y soporte [`jsdom`](#mocking-a-rendering-surface). **Si usas Create React App, [Jest ya esta incluido para usar fácilmente](https://facebook.github.io/create-react-app/docs/running-tests) con una configuracion por defecto útil.**
+- Librerías como [mocha](https://mochajs.org/#running-mocha-in-the-browser) funcionan bien en un entorno de navegador real, y puede ayudar con pruebas que necesiten de ello explícitamente.


Suggested change

- Librerías como [mocha](https://mochajs.org/#running-mocha-in-the-browser) funcionan bien en un entorno de navegador real, y puede ayudar con pruebas que necesiten de ello explícitamente.

- Bibliotecas como [mocha](https://mochajs.org/#running-mocha-in-the-browser) funcionan bien en un entorno de navegador real, y puede ayudar con pruebas que necesiten de ello explícitamente.

Darking360 · 2019-08-28T22:26:31Z

content/docs/testing-environments.md


-On Node.js, runners like Jest [support mocking modules](https://jestjs.io/docs/en/manual-mocks). You could also use libraries like [`mock-require`](https://www.npmjs.com/package/mock-require).
+En Node.js, bibliotecas como Jest soportan la [simulación de módulos](https://jestjs.io/docs/en/manual-mocks). También podrías usar librerías como [`mock-require`](https://www.npmjs.com/package/mock-require).


Suggested change

En Node.js, bibliotecas como Jest soportan la [simulación de módulos](https://jestjs.io/docs/en/manual-mocks). También podrías usar librerías como [`mock-require`](https://www.npmjs.com/package/mock-require).

En Node.js, bibliotecas como Jest soportan la [simulación de módulos](https://jestjs.io/docs/en/manual-mocks). También podrías usar bibliotecas como [`mock-require`](https://www.npmjs.com/package/mock-require).

Darking360 · 2019-08-28T22:28:17Z

content/docs/testing-environments.md


-In this scenario, you would use a framework like [Cypress](https://www.cypress.io/) or a library like [puppeteer](https://github.com/GoogleChrome/puppeteer) so you can navigate between multiple routes and assert on side effects not just in the browser, but potentially on the backend as well.
+En este escenario, podrías usar un framework como [Cypress](https://www.cypress.io/) o una libreria como [puppeteer](https://github.com/GoogleChrome/puppeteer) de forma que puedas navegar entre diferentes rutas y comprobar los efectos no solo del navegador si no potencialmente del backend también.


Aqui cambiaría libreria por biblioteca como se hablo anteriormente 😅

Co-Authored-By: Rainer Martínez Fraga <[email protected]>

Gerson4G · 2019-08-28T23:02:29Z

@Darking360 @carburo Cambios realizados

Darking360

@Gerson4G Just checking and looks good 💪 @carburo if you say so, we can merge this 🚀

carburo

Looks great! Thank you @Gerson4G

Gerson4G added 3 commits August 24, 2019 18:21

Update testing-environments.md

aced3af

Wrapping up testing-environment.md translation

51d30f3

Last re-read to translate testing-enviroment.md

451c8ed

Gerson4G commented Aug 25, 2019

View reviewed changes

carburo self-requested a review August 25, 2019 19:16

alejandronanez approved these changes Aug 27, 2019

View reviewed changes

carburo requested changes Aug 28, 2019

View reviewed changes

Gerson4G and others added 3 commits August 28, 2019 09:58

Update content/docs/testing-environments.md

dae8d7b

Co-Authored-By: Rainer Martínez Fraga <[email protected]>

Update content/docs/testing-environments.md

b8d7da8

Co-Authored-By: Rainer Martínez Fraga <[email protected]>

Update content/docs/testing-environments.md

72c936a

Co-Authored-By: Rainer Martínez Fraga <[email protected]>

Darking360 requested changes Aug 28, 2019

View reviewed changes

Gerson4G and others added 2 commits August 28, 2019 18:51

Final fixes on translation

85bf23e

Update content/docs/testing-environments.md

2fb5c4a

Co-Authored-By: Rainer Martínez Fraga <[email protected]>

Darking360 approved these changes Aug 29, 2019

View reviewed changes

carburo self-requested a review August 29, 2019 17:04

carburo approved these changes Aug 29, 2019

View reviewed changes

carburo merged commit 69d4800 into reactjs:master Aug 29, 2019

carburo mentioned this pull request Oct 5, 2019

Translate Testing and Profiler docs #273

Closed

4 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

es-testing-testing-environments #277

es-testing-testing-environments #277

Gerson4G commented Aug 25, 2019 •

edited

Loading

Gerson4G Aug 25, 2019

alejandronanez Aug 27, 2019

carburo Aug 28, 2019

Darking360 Aug 28, 2019

Gerson4G Aug 25, 2019

alejandronanez Aug 27, 2019

Gerson4G Aug 25, 2019

alejandronanez Aug 27, 2019

netlify bot commented Aug 25, 2019 •

edited

Loading

alejandronanez left a comment

alejandronanez Aug 27, 2019

Gerson4G Aug 27, 2019

carburo Aug 28, 2019

Darking360 Aug 28, 2019

alejandronanez Aug 27, 2019

alejandronanez Aug 27, 2019

alejandronanez Aug 27, 2019

carburo left a comment •

edited

Loading

carburo Aug 28, 2019

carburo Aug 28, 2019

carburo Aug 28, 2019

Darking360 Aug 28, 2019

Darking360 left a comment

Darking360 Aug 28, 2019

Darking360 Aug 28, 2019

Darking360 Aug 28, 2019

Gerson4G commented Aug 28, 2019

Darking360 left a comment

carburo left a comment


		In most cases, jsdom behaves like a regular browser would, but doesn't have features like [layout and navigation](https://github.com/jsdom/jsdom#unimplemented-parts-of-the-web-platform). This is still useful for most web-based component tests, since it runs quicker than having to start up a browser for each test. It also runs in the same process as your tests, so you can write code to examine and assert on the rendered DOM.


		This is especially useful for data fetching. It is usually preferable to use "fake" data for tests to avoid the slowness and flakiness due to fetching from real API endpoints [<small>(example)</small>](/docs/testing-recipes.html#data-fetching). This helps make the tests predictable. Libraries like [Jest](https://jestjs.io/) and [sinon](https://sinonjs.org/), among others, support mocked functions. For end-to-end tests, mocking network can be more difficult, but you might also want to test the real API endpoints in them anyway.


		In this scenario, you would use a framework like [Cypress](https://www.cypress.io/) or a library like [puppeteer](https://github.com/GoogleChrome/puppeteer) so you can navigate between multiple routes and assert on side effects not just in the browser, but potentially on the backend as well.


		### Test runners {#test-runners}
		### Bibliotecas de ejecución de pruebas {#test-runners}


		In this scenario, you would use a framework like [Cypress](https://www.cypress.io/) or a library like [puppeteer](https://github.com/GoogleChrome/puppeteer) so you can navigate between multiple routes and assert on side effects not just in the browser, but potentially on the backend as well.
		En este escenario, podrías usar un framework como [Cypress](https://www.cypress.io/) o una libreria como [puppeteer](https://github.com/GoogleChrome/puppeteer) de forma que puedas navegar entre diferentes rutas y comprobar los efectos no solo del navegador si no potencialmente del backend también.

	- Librerías como [mocha](https://mochajs.org/#running-mocha-in-the-browser) funcionan bien en un entorno de navegador real, y puede ayudar con pruebas que necesiten de ello explícitamente.
	- Bibliotecas como [mocha](https://mochajs.org/#running-mocha-in-the-browser) funcionan bien en un entorno de navegador real, y puede ayudar con pruebas que necesiten de ello explícitamente.


		On Node.js, runners like Jest [support mocking modules](https://jestjs.io/docs/en/manual-mocks). You could also use libraries like [`mock-require`](https://www.npmjs.com/package/mock-require).
		En Node.js, bibliotecas como Jest soportan la [simulación de módulos](https://jestjs.io/docs/en/manual-mocks). También podrías usar librerías como [`mock-require`](https://www.npmjs.com/package/mock-require).

es-testing-testing-environments #277

es-testing-testing-environments #277

Conversation

Gerson4G commented Aug 25, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

netlify bot commented Aug 25, 2019 • edited Loading

alejandronanez left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

carburo left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Darking360 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Gerson4G commented Aug 28, 2019

Darking360 left a comment

Choose a reason for hiding this comment

carburo left a comment

Choose a reason for hiding this comment

Gerson4G commented Aug 25, 2019 •

edited

Loading

netlify bot commented Aug 25, 2019 •

edited

Loading

carburo left a comment •

edited

Loading