Probando tu código

ReneRubalcava

<\/HEAD>

<\/P>

Escribes aplicaciones badass<\/STRONG><\/EM>. Tus usuarios están felices, tú estás feliz, todo es maravilloso<\/EM>. Alguien dice que quiere algunas nuevas funciones. Tú dices genial amigo, yo me encargo<\/EM>. Empiezas a escribir y refactorizar, añadiendo nuevos módulos, ajustando un par de otros y en algún momento toda tu aplicación se cae. Algo se rompió y has hecho tantos cambios que no puedes saber qué se rompió ni dónde.<\/P><\/P>Estás completamente jodido.<\/STRONG><\/P><\/P>Quizás nunca has estado en un escenario tan horrible, pero apuesto a que has tenido que hacer cosas feas en tu código para que las cosas funcionen porque necesitabas solucionar algún problema raro que apareció mientras añadías nuevas funciones.<\/P><\/P>La vergüenza<\/H2>Como desarrolladores, todos sentimos que deberíamos hacerlo. Quizás empezamos un nuevo proyecto con entusiasmo haciéndolo. Deberíamos estar probando nuestro código. Soy culpable de empezar un proyecto con muchas pruebas, pero en algún momento no lo mantengo y me siento horrible por ello. Pero no tiene que ser así. Las pruebas unitarias<\/A> son apropiadas para proyectos grandes, confía en mí. Quizás sea TDD<\/A> o BDD<\/A> o simplemente escribes pruebas después del hecho. Como sea que lo hagas, solo te lo agradecerás a ti mismo más adelante a medida que el proyecto crezca.<\/P>

<\/P>

Aquí hay un

repositorio sobre testing<\/A> de anteriores Esri Dev Summits y un genial ejemplo de Karma<\/A>. Me gusta Karma, es un corredor de pruebas genial, pero recientemente he revisitado TheIntern<\/A> para testing. Intern es realmente genial y puedes leer algunos excelentes posts en SitePen<\/A> sobre él. Mira el de InternRecorder<\/A> que es impresionante.<\/P>

<\/P>

Simplifica tu flujo<\/H2>La única desventaja de Intern frente a algo como Karma que nunca pude hacer funcionar es hacer que ejecute mis pruebas en la terminal con cada cambio de archivo, pero he solucionado eso usando live-reload<\/A> en mi kit de herramientas de desarrollo.<\/P>

<\/P>

Combina live-reload con

Grunt<\/A> y algunos plugins y cada vez que hago un cambio en mi app, mi app se recarga en el navegador y mi página de pruebas también se recarga para poder ver instantáneamente si rompí algo.<\/P>

<\/P>

<\/P>

<\/P>

El verde es un color hermoso.<\/P>

<\/P>

No voy a entrar en todo el tema del

rojo-verde-refactorizar<\/> parte del tdd o testing unitario. Hay muchos tutoriales ahí afuera para ayudarte con eso. También hay todo un mundo sobre espías y mocks para testing. Solo diré que me gusta b. Eso es todo. Así que es una buena manera de anotar rápidamente lo que intentas lograr. Si escribes las pruebas después del hecho, corres el riesgo de escribir las pruebas para que se ajusten a tu código, que podría estar roto. BUT, si vuelves a ejecutar estas pruebas mientras escribes más código, al menos sabrás si rompiste algo que funcionaba antes.

Hay muchos recursos sobre pruebas en JavaScript disponibles. Aquí hay un par que puedo mencionar.

Introducción a las pruebas unitarias en JavaScriptRecetas de pruebas en JavaScriptIntern Tutorial esri jsapiAquí hay un proyecto demo que incluye pruebas y herramientas grunt para ayudarte.Para más consejos y trucos geodev, visita mi blog.