<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Unit Testing on csegura</title><link>https://blog.romheat.net/tags/unit-testing/</link><description>Recent content in Unit Testing on csegura</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Mon, 03 Nov 2008 00:00:00 +0100</lastBuildDate><atom:link href="https://blog.romheat.net/tags/unit-testing/index.xml" rel="self" type="application/rss+xml"/><item><title>Sharepoint Unit Testing</title><link>https://blog.romheat.net/posts/2008/08_11_03_unit_testing_2/</link><pubDate>Mon, 03 Nov 2008 00:00:00 +0100</pubDate><guid>https://blog.romheat.net/posts/2008/08_11_03_unit_testing_2/</guid><description>&lt;p>Como sabéis tanto Gustavo como yo llevamos tiempo realizando pruebas sobre lo que programamos en SharePoint, ambos estamos usando TypeMock como framework para
nuestros objetos Mocks que son imprescindibles a la hora de realizar pruebas para SharePoint.&lt;/p>
&lt;p>Durante los últimos meses hemos posteado sobre el tema, hemos iniciado un proyecto en CodePlex con un conjunto de clases envoltorio que pueden ayudarnos a
la hora de realizar las pruebas con TypeMock y que está a un tris de quedarse obsoleto.&lt;/p></description></item><item><title>Unit Testing</title><link>https://blog.romheat.net/posts/2008/08_09_21_unit_testing/</link><pubDate>Sun, 21 Sep 2008 00:00:00 +0100</pubDate><guid>https://blog.romheat.net/posts/2008/08_09_21_unit_testing/</guid><description>&lt;p>Aquí continúa el drama de Unit Test para SharePoint. Esta vez hemos reunido esfuerzos entre nosotros, Carlos Segura (&lt;a href="http://www.ideseg.com" target="_blank">http://www.ideseg.com&lt;/a> ) y Gustavo Velez (&lt;a href="http://www.gavd.net" target="_blank">http://www.gavd.net&lt;/a> ), para intentar sacar algo en claro. Programadores del mundo de SharePoint, uníos! …&lt;/p>
&lt;p>Unit Test, SharePoint y que es lo importante:&lt;/p>
&lt;p>Testeo Unitario es una técnica de programación que permite asegurar que lo que se ha programado hoy cumple las condiciones exigidas, y que las seguirá cumpliendo en el futuro, cuando se hagan modificaciones en el código fuente. Existe numerosa información al respecto, tanto en libros de texto como en internet, así que no repetiremos las bases de la técnica; en resumen, es deseable que se
cumplan algunas condiciones:&lt;/p></description></item><item><title>Unit Testing 3</title><link>https://blog.romheat.net/posts/2007/07_12_12_unit_testing_3/</link><pubDate>Wed, 12 Dec 2007 00:00:00 +0200</pubDate><guid>https://blog.romheat.net/posts/2007/07_12_12_unit_testing_3/</guid><description>&lt;p>Alguien me ha recordado que empecé a escribir sobre el tema de las pruebas unitarias y finalmente no termine… o por lo menos no conté algunas de las prácticas que uso… cierto.&lt;/p>
&lt;p>&lt;strong>&lt;a href="https://web.archive.org/web/20130623113708/http://www.ideseg.com/SharePointPruebasUnitarias1.aspx" target="_blank">Parte 1&lt;/a>&lt;/strong> – &lt;strong>&lt;a href="https://web.archive.org/web/20130623113708/http://www.ideseg.com/SharePointPruebasUnitarias2.aspx" target="_blank">Parte 2&lt;/a>&lt;/strong>&lt;/p>
&lt;p>Básicamente la técnica que uso habitualmente consiste en aprovisionar un sitio de forma automática. Y ¿Cómo se aprovisiona un sitio automáticamente?, pues de la manera más sencilla posible. Usando Plantillas.&lt;/p>
&lt;p>&lt;strong>Provisión – Escenario de Pruebas&lt;/strong>&lt;/p></description></item></channel></rss>