Ver por etiquetas
Todas las etiquetas »
XP »
Arquitectura (
RSS)
Una de las características más importante que debe seguir cualquier código y que es particularmente importante en las pruebas de cualquier tipo es la claridad. Una prueba debe entenderse a la primera sin demasiado esfuerzo, por eso es que debe ser breve, clara y desprovista en el mayor grado posible de elementos ‘ruidosos’. Uno de esos factores ruidosos son los frameworks de aislamiento, los mal llamados Mocking Frameworks. Es por esto que limitar su uso a aquellas ocasiones verdaderamente justificables...
Las pruebas unitarias debería ser así de cortas y claras: using System; using System.Collections.Generic; using System.Linq; using System.Text; using NUnit.Framework; using Losoft.Temo.Security.Authorization.Exceptions; namespace Losoft.Temo.Security.Authorization.Tests { [TestFixture] public class AdminGroupSpecs : TestsWithSecurable { [TestCase( "R" ), TestCase( "W" ), TestCase( "V" ), TestCase( "A" )] public void Will_Allow_All_Operation_To_Admin_Accounts...
Las recientes experiencias en la industria confirman que para obtener mejoras sustanciales mediante pruebas unitarias es necesario incorporar TDD (Test-Driven Development) como práctica integral del desarrollo. Aunque TDD no es una práctica nueva, solo experiencias recientes en Microsoft, IBM, HP y Ericsson comprueban la efectividad y factibilidad de ésta en proyectos reales y de reputación mundial. Los números de los resultados en realmente asombrosos. Les recomiendo leer las siguientes publicaciones...
Imagina que encontramos un clase estática con varios métodos estáticos los cuales tienen una cantidad aberrante de parámetros. Queremos eliminarla pero nos damos con que está siendo usada en muchísimas partes ¿que hacemos? ¿Como lo harias vos?. Para hablar más concretamente veamos uno de esos métodos: public static void CreateActivityLog( string containerSourceId, string containerId, string action, string sourceId, string instanceId, string docNo, string notes, IFrameworkSecurityContext credentials...
Desarrollar con TDD al principio no es nada fácil pero luego se vuelve “la manera” de desarrollar. Ahora, no siempre hago TDD, si quiero probar algo tan solo tiro las lineas y listo pero, por otro lado, si quiero hacer algo bien por más que tenga algo de código hecho lo tiro y lo comienzo de nuevo con TDD (nunca he perdido mucho. Por el contrario, lo hago porque veo una diferencia). El asunto es que diseñé una interface fluida para encapsular todos los detalles indeseables de la manipulación de documentos...
Hace poco gravé un pequeños video en el que explicaba una realidad que he visto en muchos proyectos respecto de las pruebas unitarias. En síntesis lo que comentaba era que en esos proyectos, los beneficios de las pruebas unitarias no eran visibles mientras que los costos sí lo eran. En problema aparente era la calidad de las pruebas, pero en realidad, el problema de fondo es la estrategia de hacer las pruebas luego de terminado el código. Por lo general, los programadores escriben piezas de código...
Hace poco comencé un nuevo desarrollo y decidí grabar algunos videos de los cuales solo publiqué los primeros tres. Sucede que el hecho de saber que alguien me estaba mirando me hacía prestar mayor atención a mis palabras que al código que debía escribir. No obstante a ello, continué grabándome para tomar el tiempo y estudiarme. La primera parte de ese desarrollo está completado y estos son los números: 66 pruebas unitarias. 15 clases. (solo 4 centrales, el resto son datacontracts, excepciones y...
Tengo que hacer un sistema de autorización para un sistema algo complejo y me pareció que sería bueno mostrar como se programa/diseña mediante TDD (Test-Driven Development) por lo que gravé las sesiones. Espero que les sirva. (TDD - Ejemplo) Security Access Control 1/X from lucas ontivero on Vimeo . (TDD - Ejemplo) Security Access Control 2/X from lucas ontivero on Vimeo . (TDD - Ejemplo) Security Access Control 3/X from lucas ontivero on Vimeo . Continuará….