Si tenemos una visión diferente de cómo debe funcionar el equipo, no conseguiremos llegar a ella porque cada uno rema en una dirección distinta.

Puede que tan sólo sea cuestión de detenerse un momento, reflexionar y decidir qué significa ser integrante de este equipo. Consensuar con los demás los valores y principios que
nos parecen claves. Y que de ese consenso busquemos prácticas que nos ayuden a ser el equipo que queremos y nos hagamos fuertes.

Un principio que me gusta aplicar es el de hacer con los demás lo mismo que me gustaría que hiciesen conmigo.

Así que voy a pensar cómo me gustaría que fuese un compañero de mi equipo para poner yo mismo en practica esos hábitos.
Voy a hacer mi propia lista de "me gustaría...", la cual podemos completar entre todos los miembros del equipo. Aquí va.

Me gustaria que un compañero... (o compañera, por supuesto)

• Me pudiese cubrir perfectamente cuando estoy enfermo o de vacaciones sin que me tengan que llamar por teléfono contínuamente o pedirme que me conecte remotamente cuando no me encuentro en condiciones para ello.
• Se tomase el tiempo de explicarme lo que sabe para que cuando se marche de vacaciones o se ponga enfermo, no me sienta totalmente perdido.
• Me pidiese ayuda o hiciese programación en pareja conmigo cuando conozco mejor el código o el negocio que él o ella, porque así ganamos tiempo y aprendemos todos a la vez.
• Me pidiese ayuda o trabajásemos juntos cuando sabe que el código que tiene que modificar es complejo y prefiere estar seguro de que no rompemos nada.
• Me enseñase técnicas y prácticas que conoce para ser mejor profesional.
• No me hiciese contarle más de tres veces una técnica de desarrollo sin que la tenga anotada y estudiada.
• Trate de asegurarse por todos los medios que los cambios que ha introducido en el código no rompen funcionalidad existente (no introduce defectos).
• Ejecutase los tests antes de subir su código al repositorio para evitar que me tenga que poner a arreglar tests que se han roto con cambios que no he hecho yo.
• Tuviese la iniciativa de arreglar un test que no ha roto él o ella, cuando el compañero que lo rompió por accidente, ha sido avisado, pero no se puede poner con ello en ese momento. (Si quien ha dejado el test roto no suele romperlos sino que se trata de un caso excepcional).
• Revisase mi código para entenderlo, detectar mejoras o sugerirme alternativas.
• Criticase mi código constructivamente para ayudarme a mejorarlo y a superarme yo mismo.
• Usase las partes de la aplicación que he hecho yo, para darme feedback como usuario.
• Me pudiese sustituir en cualquier momento dándome la seguridad de que lo va a intentar hacer igual de bien que lo intento yo.
• Esté abierto a recibir críticas constructivas y a aprender cada día.
• Reconozca sus errores y se esfuerce por no cometer el mismo muchas veces.
• Se alegre por mi progreso profesional y me apoye para que siga mejorando.
• Tenga la iniciativa de aplicar cambios sobre código que he escrito yo, cuando necesita ser ampliado funcionalmente y yo no lo pueda hacer en ese momento (porque esté ocupado con otra tarea). Que no me haga sentir que soy el cuello de botella sino que me ayude a quitarme la presión de encima. Y que cuando cambie el código se asegure de que todos los tests siguen pasando y ha puesto el mismo nivel de cuidado en el código que el que he puesto yo.
• Cuando tiene que introducir deuda técnica porque no le queda más remedio, lo anote y vuelva al código a saldarla tan pronto como el momento de presión termine.
• Cuando tiene que modificar código de baja calidad se esfuerza por mejorarlo y no sólo por añadir a trancas y barrancas la nueva funcionalidad sobre la maraña.
• Se cuestione si está haciendo lo mejor posible en cada momento y rectifica para ir en esa dirección.
• No haya que repetirle las cuestiones con las que ya en otra ocasión hemos acordado que nos vamos a comprometer.
• Escriba código que puedo entender sin tener que preguntarle a nadie. Y además lo puedo ampliar y testear con facilidad.
• Antes de tomar decisiones que tienen repercusión sobre los demás, las discuta con los implicados.
• Si no está de acuerdo con algo que digo, tenga la sinceridad de decirmelo a la cara en el momento adecuado, mejor que a destiempo.
• Por tanto el equipo que yo visualizo se mueve en bloque, es homogéneo porque comparte unos valores y principios.

En mi visión de equipo no entra esto de "yo hago mi parte y tu la tuya", y cuando pasa algo en la parte que es "tuya" te llamamos para que la arregles tu. En una situación excepcional si, no hay reglas fijas ni matematicas puras para el día a día.

En esta visión tampoco hay tareas que siempre hace la misma persona porque es la única que sabe y parece que siempre va a seguir siendo así.
No puede haber personas que parecen ser imprescindibles. En realidad nadie lo es por muy alto que sea su bus factor. La vida sigue aunque unos marchen y otros lleguen.

Pero mi visión de equipo no sirve si mis compañeros no la comparten.

El compañero al que recuerdo con una sonrisa es el que me lo pone fácil en el día a día. El que no me obliga a verme sometido a presión innecesaria por un trabajo que él o ella ha hecho con neglicencia. Que no me obliga a hacer horas extra por su falta de cuidado.

Ser un amigo no tiene por qué ser lo mismo que ser un buen compañero. Ser un tío majo y agradable no significa ser buen compañero. Es de agradecer tratar con compañeros agradables pero eso no hace un buen equipo por sí sólo.

Puedes rellenar este interesante cuestionario sobre el nivel de agilidad de tu equipo y reflexionar sobre los resultados: http://www.abetterteam.org/new

Animaría a los equipos a redactar su propia lista de cualidades de un miembro del equipo y a colgarla en una pared grande, donde siempre sea visible para todos. Que nuestro ego no se pase por el forro esa lista sin que se note, sino que de el cante y podamos poner a ese ego en su sitio en favor de los valores del grupo.

No es otro que el ego quien causa problemas a individuos y grupos. Hay que vigilarle.

Conozco demasiados programadores que van a la última en tecnología, pero que NO lo necesitan.

Probablemente cuando sacan de la funda el último móvil o el último portátil que acaban de comprar se sientan más importantes. Esto es lo que vende la televisión y la publicidad en general de las grandes marcas. Yo sin embargo no puedo evitar pensar que es una persona excesivamente consumista. A su vez eso puede significar que:

• Aún vive con sus padres. Sus niveles de madurez, iniciativa y responsabilidad son mediocres.
• Nunca se ha parado a pensar en el impacto que la fabricación de ese hardware tiene sobre el planeta y sobre los pobres chinos que están explotados fabricandolo. Esto es falta de compromiso con el planeta, que lo está pidiendo a gritos.
• Es muy probable que jamás haya donado dinero para ninguna causa social, animal o medio ambiental. Ni siquiera a su proyecto open source favorito. De nuevo, poco compromiso. Puede que resultase ser un compañero demasiado egoista como para hacer un buen equipo.
• Es demasiado materialista como para importarle el crecimiento personal de sus compañeros lo suficiente.
• Es una persona que compra compulsivamente porque no tiene claras sus metas, no sabe por qué razón se levanta cada mañana.

No tienen que cumplirse todos los puntos, incluso puede que ninguno. Si los lees y te pica, entonces tu sabrás. Pero esto no es malo si te sirve para reflexionar sobre ello. Simplemente significa que tienes que deternete un momento y pensar más en lo que haces y en por qué lo haces. Que lo hagan todos tus amigos no significa que sea correcto. Has venido al mundo para hacerlo un sitio mejor, igual que mejoras el código legado cuando pasa por tu manos, aunque te llegue lleno de mierda hasta las trancas. Esos son los valores que necesitamos para practicar XP.

No necesitas mirar twitter cada 5 minutos. Piensa en la manera en que estas faltando el respeto a la persona que ha quedado para tomar café contigo, cuando estas escribiendo un tweet vació sobre el bonito uniforme del camarero. Los móviles que se vendían hacen pocos años tienen una batería que dura una semana entera. Se habla por telefono de puta madre y se pueden enviar mensajes SMS. ¿Necesitas poder consultar tu email en el tren? Ok, te vendrá bien un smartphone. ¿Pero de verdad no puedes esperar a gestionar tu email con tranquilidad? Seguramente el conductor del autobus se sentirá mejor si al subirte le das los buenos dias en vez de ir escribiendo en tu telefono nuevo. Puedes mandarle un tweet de buenos dias pero es más rápido que se los digas de boca a oreja.

No necesitas que tu portatil tenga 4 núcleos, 8gb de ram y una SSD de 200gb si trabajas con un pc de sobremesa que ya tiene las prestaciones suficientes. Si es tu herramienta de trabajo principal y realmente eres más productivo con ese hardware, adelante, se productivo. ¿Pero es de verdad tu necesidad? Los portátiles que fabricaban hace 6 años siguen corriendo perfectamente Linux y Windows. Con renovar la batería y ampliarle un poco la ram, van de lujo.

Ahora está de moda comprar un portatil Mac. Si vas a un evento y no tienes uno pareces un aficionado. Ya sabemos todos la polémica que hay con la fabricación de los Mac en cuanto al nivel de explotación en las fábricas y a pesar de ello... ¿es de culto tener uno?. Por desgracia pocas serán las marcas que se preocupen por las personas y el medio ambiente. Si eres más productivo con MacOS, está bien pero ¿no te vale con uno de segunda mano? ¿se van a reir de ti tus amigos? Yo no tengo un Mac, porque ahora mismo en el trabajo uso forzosamente Windows y en casa llevo una década usando Linux y encuentro que soy suficientemente productivo con el. Tengo Vim, Emacs y mucho mas!
Por cierto que el stack tecnologico del trabajo me obliga a usar un pc sobremesa del copon gracias a que Microsoft no repara en recursos con sus sistemas operativos. Intentaremos usar Windows 7 por 20 años porque para la siguiente version, nos va a hacer falta un reactor nuclear. Es otra opción que hay que barajar, no actualizar de version Windows hasta que no quede otro remedio. De hecho Windows XP va estupendo para todo lo que no sea Visual Studio 2010.

¿Esto significa ser antiprogreso? Solo significa tomar las decisiones por motivos bien claros y no por parecer mas geek. Ser más geek mina los proyectos, las relaciones con los clientes, la relación con los compañeros y hasta calidad del software. ¿A ti te pega que Martin McFly llegase a casa con su skate volador y escribiese métodos de 5 lineas? A mí no.

¿Eres tu McFly con los aparatos mágicos? ¿tal vez el Inspector Gadget?

Si no te habías parado a pensarlo, ya sabes que eso no te hace más profesional a los ojos de todo el mundo. Para ser más profesional y una persona más integra, hay que prestar atención y practicar. En ello estamos. Si puedo ayudarte, grita, yo también estoy intentando aprender todo esto

Aquí dejo un video que me parece fenomenal con Joán Melé hablando del dinero y la crisis. Yo la crisis no la estoy percibiendo economicamente en mi trabajo (sí en mi familia) pero sí que percibo una crisis tremenda en el sector por una falta de valores que nos permite ser ágiles de verdad.
 

 

Así que hemos pensado que hasta estabilizar la situación, dejamos los sprints semanales y hacemos un sprint por cada historia de usuario. Lo primero que se hará con la historia es sacar con la máxima precisión los criterios de aceptación. Escribiremos tests end-to-end al inicio de la historia (siempre que el codigo legado nos lo permita) que validarán su consecución. Así sabremos con exactitud lo que está terminado y sabremos que funciona. Además la figura del middle-man que traduce las charlas con el cliente en historias y criterios de aceptación se diluye un poco y todo el equipo se encarga de analizar y conseguir esos criterios: Más cohesión entre análisis-negocio y desarrollo.

El equipo de QA se convierte en un cuello de botella por deficiencia del proceso (o ausencia). Decidimos que los responsables de QA tendrán un pequeño meeting diario para ver cómo van las incidencias. Los jueves se hará especial esfuerzo en probar todo para confirmar que se puede desplegar en producción.

Además dedicaremos el último pomodoro del día a probar entre todos las tarjetas que están en estado "listo para UAT" para que lleguen más filtradas al equipo de QA.

Es prioritario reducir al mínimo la distancia entre el código que hay desplegado en producción y la rama principal del control de versiones. El ideal es poder desplegar en cualquier momento la rama principal, ya que usamos ramas para funcionalidades que están sin terminar. No obstante, a veces nos gustaria desplegar aunque haya funcionalidad a medias. Por eso vamos a intentar seguir puliendo la técnica de feature branches y además añadir en alguna ocasión feature toggles.

La información del kanban al final de la semana no va a parar a ningún documento histórico ni estadístico. Esto va a cambiar ya, para que tengamos el registro más fiable posible de costes en el corto, medio y largo plazo. Me encargo yo mismo. Esta información lógicamente no será pública

La mejora contínua sigue adelante y en estas semanas hemos avanzado con paso firme en lo siguiente:

• Hay menos interrupciones. Antes de interrumpirnos entre nosotros nos preguntamos por skype o email y al terminar el pomodoro hablamos entre nosotros.
• Estamos más concienciados con probar a mano las tarjetas antes de pasarlas al equipo de QA.
• Cada día nos preocupa más la deuda técnica y pensamos más antes de programar.
• Las reuniones diarias (daily meeting) van cada vez más fluidas, tardamos entre 10 y 15 minutos.
• Las reuniones de retrospectiva son más directas y nos dan más información.
• El número de tests automáticos sigue creciendo y su calidad también. Hemos alcanzado ya los 500 tests con javascript.
• Hemos hecho varias mejoras de arquitectura sin que el cambio sea muy costoso ni traumático.
• Hablamos más unos con otros y discutimos sobre código y arquitectura en el proyector antes de lanzarnos a programar lo primero que se nos ocurre.

El camino es largo, pero vamos mejorando hacia XP. Sólo hay que seguir vigilando para no retroceder y seguir practicando la honestidad, la valentía de hacer lo que es bueno para uno mismo (y eso será lo mejor para el equipo) y el sentido común. Ser consecuentes con lo que se hace y constantes con las prácticas.

• The basics:

In order to send or retrieve objects to or from the database, you need a DataContext instance. This is an instance of a class that inherits DataContext. It is created by Visual Studio with drag and drop. One context is generated for every database you access to. This generated context is inside a .cs file which contains also the classes that map database tables. The mapping is contained in a .dbml file (xml) generated in the same folder. You should not change any of this generated files. If a table changes in the database you must regenerate with the IDE.

Select example:
If the name of the database is ProductionDB, the DataContext will be ProductionDBDataContext.

var context = new ProductionDBDataContext(connectionString);
var userEntity = (from user in context.Users
	where user.name == "carlos"
        select user).First();

Insert example:

var context = new ProductionDBDataContext(connectionString);
var user = new User();
user.name = "manolo"; 
context.Users.InsertOnSubmit(user);
context.SubmitChanges();

• The main issue:

The same context instance have to be used for all the operations performed on a relational object instance. This would throw an exception:

var context = new ProductionDBDataContext(connectionString);
var userEntity = (from user in context.Users
	where user.name == "carlos"
        select user).First();
// Imagine this is part of another method in another place
// but with the same userEntity instance that was passed through:
userEntity.age = "30";
var otherContextInstance = new ProductionDBDataContext(connectionString);
otherContextInstance.Users.InsertOnSubmit(user);
otherContextInstance.SubmitChanges();

So you can't just pass relational objects from one method or layer to anoter, you have to always cope with the "same context instance problem".

•  Solutions

1. Pass the context instance along with the relational objects, in all the places where you need to perform database access:   someMethod(user, context);
   Bad choice: This leads to spaguetti code quickly. Why  does my business layer have to know about a database context?
2. Ok so we can make a Singleton for the context instance and make sure it is the same for all the application:
   public static ProductionDBDataContext AppContext = new ProductionDBDataContext(connString);
   Bad choice: When more than one request hit the server at the same time you get concurrency problems. The context will be trying to insert in one thread while trying to update or select in other. Weird race conditions happens and exceptions are thrown.
3. Create a context for every thread. Every thread will have its own context Singleton. We found this solution thanks to Rick Strahl and his great post. However Rick's code can be simplified this way:

public class ContextFactory
{
	[ThreadStatic]
	private static ProductionDBDataContext context;
	private string connString = "settings to access the database ...";
 
	public static DataContext Context(){
		if (context == null)
			context = new ProductionDBDataContext(connString);
		return context;
	}
}

The ThreadStatic attribute ensures that every thread will access a different instance. So the "context" is not shared amont threads. This simplifies Ricks's code. But our problems didn't stop here unfortunatelly

You might expect the thread to die when the response is sent back to the client side, but it doesn't. Sometimes IIS reuses the thread for other requests, and the context is not a new, fresh instance. Moreover, the context caches some queries and that leads to several issues:

1. The optimistic concurrency control nightmare. The default behavior is for "Linq to Sql" to check every db column on update, to see if there are more than one simultaneous attemp to persist the entity. If so, it raises the ChangeConflictException. This can be avoided by editing the dbml and marking every column with "Never" in the UpdateCheck property. Guess that.... when you regenerate the dbml file, this is overwritten and you loose your configuration. More information on conflicts here.
   One way to deal with conflicts is to catch the exception and force the update:

   var someEntity = ... // query here
   try
   {
       context.SubmitChanges(ConflictMode.ContinueOnConflict);
   }
   catch (ChangeConflictException e)
   {
      context.Refresh(RefreshMode.KeepCurrentValues, someEntity);
   }

   However, this does not avoid the cache invalidation problem.

2. The cache invalidation problemis the last one we have found and solved so far. The solution is to drop the cache as the new request enters the server. To refresh the cache just create a new instance of the context:

   public class ContextFactory
   {
   	[ThreadStatic]
   	private static ProductionDBDataContext context;
   	private string connString = "settings to access to database ...";
    
   	public static DataContext Context(){
   		if (context == null)
   			context = new ProductionDBDataContext(connString);
   		return context;
   	}
   	public static void FlushContext(){
   		context = new ProductionDBDataContext(connString);
   	}
    
   }

   Then, in the first layer of the server side (where the request is received) we call FlushContext to make sure it is new for this request. (For us is our JsonRpcController, a custom make controller hierarchy).

For now, we can rest assured that our DataContext is:

• Unique for every thread so it is thread-safe.
• Unique for every request so there are no cache problems among different requests.
• If two different parts of the application need a context's instance in the same request, our factory gives a single reference (Singleton), making sure that only the first access initializes it (because we check whether it is null before instantiating).

Los metodos y funciones deben devolver un solo resultado y en ocasiones, ninguno (void). ResponseDTO se puede considerar "un solo resultado" cuando los campos "success" y "message" se necesitan el uno al otro, tal que no tiene sentido el objeto sin los dos campos. Es decir cuando el objeto es lo más atómico que la operación puede devolver. ResponseDTO se ideo para enviar a cliente (js) respuesta a determinados comandos que solicita al servidor pero no debería usarse en las otras capas de la aplicacion.

¿Dónde lo usamos mal? Tenemos métodos con un nombre interrogativo que denotan retorno boolean y sin embargo devuelven uno de estos ResponseDTO:

• IsExistingUser
• DoesPolicyExists
• IsValidInput

Para cualquiera que lea la API, no es intuitivo. ¿Para qué sirve el "message" del objeto cuando el método "IsExistingUser" retorna? Para nada.

En la validación, puede tener sentido este objeto response dependiendo del contexto: Si el error de validación puede considerarse una circunstancia excepcional, entonces lo mejor es lanzar una excepción que alguien de nivel superior recogerá. Por tanto, sobra el objeto response ya que la excepción llevará el mensaje de validación particular. Si un problema de validación no se considera una circunstancia excepcional, entonces puede estar bien devolver el response con su success puesto  a false y su mensaje concreto.

Más sitios donde lo usamos mal: Métodos que disparan acciones hacia fuera de nuestro sistema

•  SendEmail
•  SaveUser

Los métodos que provocan acciones que salen de los límites de nuestro código (acceso a BD, a un servidor de correo, etc) no pueden garantizar la correcta consumación de la acción. Por tanto, jugar a devolver boolean para exito o fracaso es engañarnos.
Es preferible un método void que funciona sin hacer ruido cuando todo va bien y que lanza excepciones cuando se encuentra con una situación inesperada. Por ejemplo, el método que solicita el envio de un email, puede defenderse de excepciones que provoque la libreria de SMTP y traducirlas en excepciones de nuestro dominio, tales como EmailSendFailure (una excepción nuestra que hereda de ApplicationException).

¿Y es tan grave que usemos el ResponseDTO? Sí que lo es porque el código que consume esos métodos se convierte en spaguetti:

var isNotValidData = !InputValidator.ValidateUserData(
                          policyHolder.Person).success;
if (isNotValidData)
{
	response.message = Strings.T("Los datos son incorrectos.");
	return response;
}

Del método "ValidateUserData" sólo nos interesa el campo "success", el mensaje lo está generando el llamador. No sólo es raro de leer sino que es un coñazo a la hora de escribir tests de interacción. Cuando queremos que en un test de colaboración, este método devuelva falso, tenemos que especificar que devuelva un objeto con un campo a falso. Si fuera boolean, no tendriamos que especificar nada porque el valor por defecto sería false. Esto va al hilo del posts de los tests de interacción limpios.

En el caso de métodos de acción como el envio de email, es incluso peor porque quien consume el método pensará que con un resultado verdadero el email ha llegado a su destino, como si eso lo pudiesemos asegurar de alguna manera.

Para saber qué debe devolver un método, este debe tener una única responsabilidad y debemos saber cual es. Y la mejor manera de saberlo, para mi siempre es escribir el test antes que el código.

In order to write cleaner interaction tests (those which use test doubles; mocks, spies, stubs) you should understand how your test doubles framework works. Interaction tests can be extremely difficult to read and maintain and very fragile if you don't pay enough attention. We will review Mockito, Moq, Jasmine and pyDoubles.

Mockito and Moq create a double object by inheriting the original and overriding its methods. pyDoubles uses interception rather than inheritance. Jasmine is different because it does not double the whole object, but just the method you spy on. So there is a big difference: Mockito, Moq and pyDoubles replace the whole object while Jasmine replaces just one method.

So Jasmine leaves space for a bad testing practice: Spy on one method of the object while testing other method of the same object. Interaction tests are intentded for object collaboration. Testing that one method calls another method within the same object is not recommended. It means that the object has more than one responsibility or that you want to know more about the object's inner behavior than you should, so you are breaking encapsulation. This is not a Jasmine problem, the problem is yours if you don't use the tool properly.

There are three primary reasons to replace method calls on collaborators:

1. You want to avoid a database call just to keep the test unit fast and repeatable (stub the method - use a stub object)
2. You want the method to return some value to simulate the response (stub the method - use a stub object)
3. You want to make sure that a call is made (spy or expect the call - use a spy or a mock object)

For case numer 1, you don't have to specify the returned value. Just use the stub object and let the framework return whatever it wants. Mockito and Moq, return the default value for the method, when no other behavior is specified:

• If the method returns an integer, a call to that method in the stub object, will return cero (default value for integers)
• If the method returns an object (reference type), a call to the stub method will return null (default for objects)
• False for booleans and so on...

However, be careful with Moq because in C#, if the original method is not virtual (contains the virtual keyword), Moq can't stub it out, so the original will be called. Moq fails if you specify a behavior on that method but if you don't, it calls the original instead of returning the default value.

pyDoubles always returns None no matter the method signature.

For case numer 2, you define what the returned value should be. Using "when" in Mockito and "Setup" in Moq.

For case numer 3, you verify that a call was made:

• Mockito: verify(double).method();
• Moq: double.Verify(x=>x.method());
• pyDoubles: assert_that_method(double.method).was_called()
• Jasmine: expect(double.method).toHaveBeenCalled()

You might want to know what parameters were passed in too. In this case you can use Matchers in Mockito, Moq and pyDoubles.

Moq sample:

userRepository.Verify(x => x.SaveNewUser(
        It.Is<Person>(
        p => p.PersonalIdentificationCode == "TEST_CODE")));
 

pyDoubles sample:

assert_that_method(double.method
         ).was_called().with_args(obj_with_fields({
                            'id': 20,
                            'test_field': 'OK'}))

For Mockito samples I am waiting for my friend @regiluze to write a post on it I will link it here when written.

Jasmine sample:

spyOn(double, "method").andCallFake(function(){
      expect(arguments[0].name).toEqual("Carlos");
});

Test collaborations one to one:

If the object under test has more than one collaborator, tests can be really hard to understand. I recommend expressing every collaboration in a single test:

• A talks to B (test 1)
• A talks to C (test 2)

• For test1, B will be a spy o mock (you use Verify at the end). Also for test1, you don't care about C, C is just a dummy. Calls to C don't need to be configured in the double, let the framework return the default value.

• For test2, C is the spy or the mock, you verify interaction between A and C, and do't care about B. Calls to B don't need to be configured, let the framework return whatever.
• For test1, if the value returned by C, is necessary for the collaboration between A and B, then Ok, specify the stub result for that call to C, and verify on B.

Group the tests by setup:

Should I have a test class for every class in the production code? NO.  Tests must be grouped by their setup. This is, put those which have the same arrangement in the same test case (test class). If there are two or more interaction tests in a class, the creation of the SUT and the doubles, should not be in every test. It must be in the setup, along with the injection (doubles, are injected to the SUT as collaborator). So, if you find yourself injecting the test double to the SUT in more than one test, watch them again carefully.

Cada cambio era una patada a mi ego, porque me sacaba de la zona de confort y me hacía sentir que perdía mi valía, la maestría de la herramienta que tanto me habia trabajado.

Y resulta que en lugar de perder, estaba ganando. Si no hubiese tenido que pasar obligado por todos estos cambios, no tendría la visión que tengo hoy en día sobre patrones, técnicas de programación, arquitecturas ... la tranquilidad de que me cuesta muy poco adaptarme a una nueva plataforma porque siempre contiene elementos de otras que ya conozco. Me da seguridad en mi mismo y me ha quitado por completo el apego a las herramientas. Programo en lo que sea y estoy deseando seguir aprendiendo lenguajes, frameworks.

Disfruto programando cualquier lenguaje y sé qué elementos me interesan usar de un framework y qué otras partes me puedo saltar. Solo porque he tenido que trabajar en muchos.

Ahora que estamos buscando gente para que se una a nuestro equipo, donde usamos mayormente .Net con C# y por otro lado Javascript, sé que mucha gente no tiene interes porque no quiere abandonar su stack tecnológico de siempre. Parece que programar .Net fuese lo peor del mundo, cuando es tan solo una copia de Java que lo mejora en muchos aspectos. Se van copiando el uno del otro. Además puedes usar F#, IronPython, IronRuby, Boo, y aprender de algunos de los programadores más increibles del planeta.

Me parece muy bien que la gente tenga predilección por frameworks como, Django, Symfony, Rails o Grails pero la negativa a usar otra cosa, tal como yo lo veo, es una cuestión de apego  poco racional. En algunos casos, yo diría que inmadurez. Además, los proyectos no duran para siempre, son etapas, son transiciones como la vida misma.

Todos los que me habeis dicho personalmente (amigos mios) que nos veníais por el stack tecnológico, creo que aún teneis que seguir madurando profesionalmente.  Y yo tambien, por supuesto. Lo digo sin rencor ni enfado de ningun tipo.

Contínuamente me digo a mí mismo... no dejes que el ego frene tu aprendizaje

Typical way to stub out a method call with mockito:

when(colaborator.method(argument1)).thenReturn(whateverIwant);

Same with Moq:

colaborator.Setup(x => x.method(argument1)).Returns(whateverIwant);

Obviously, the mockito way is nicer. I believe this is because of Java capabilities but I am not sure. I would like to dig into mockito's source code to see how is this possible. I will do it and blog about it soon. I used to think that it was because of the kind ot late binding supported by Java, but I am not sure.

Moq uses a lambda expression (anonymous method inlined) to tell the framework which method and how is expected to be called). The reason I use "x" for the object in the anonymous method is because it refers to "colaborator" itself so there is no point in adding more names.

The other important difference relates to the "virtual" keyword in C#. Methods in C# are final by default. You can't override them unless they contain the keyword "virtual" on its signature. Both, Mockito and Moq create test doubles by subclassing on runtime, overriding methods and implementing the fake behavior on them (as far as I know). So, if the method you want to stub is not virtual, Moq will throw a runtime exception. If it is not virtual but you don't specify any fake behavior on it, it will not throw exceptions, but worse, it will call the actual implementation. So you might be hiting the database in your unit tests inadvertedly. What I do, is that all my methods are virtual by default (I write "virtual" on their signature).

There will be more posts on this topic

• Que cuando reimplementemos una funcionalidad (o una similar a otra que ya tuviesemos), contemos con las personas que desarrollaron la primera versión. Lo ideal es que las personas que estuvieron en el primer desarrollo estén haciendo pareja con quienes se enfrentan al problema por primera vez. Si no es posible, al menos deben sentarse a hablar de las dificultades que surgieron con la primera implementación y las soluciones que se encontraron.
  Lo primero será tratar de evaluar si se puede reutilizar parte del código existente. No siempre es fácil tomar esta decisión pero por lo menos hacer un estudio rápido de la situación. En caso que se pueda reutilizar, estudiar qué se debe refactorizar y a qué se le pueden añadir tests. En caso que haya que reescribirlo todo por completo, tener presentes las ideas que ayudaron más al buen funcionamiento de la primera implementación. Esto es: aprovechar la experiencia que ya tenemos.
• Separar muy bien lo que es importante de lo que es urgente. Si todo es urgente, dejamos de saber lo que es importante. Nos ha pasado y nos ha perjudicado. Cuando digamos que algo es urgente, tendremos que saber que corremos peligro de dejar atrás lo imporante.
• Tratar de evitar la entrada de imprevistos durante el sprint. Tiene que ver con lo anterior. Si surge una necesidad el jueves y no es bloqueante, debemos plantearnos esperar a abordarla el lunes, es decir, en el siguiente sprint. La idea es no romper la planificación semanal. Cuando la rompemos, nos distanciamos de los objetivos propuestos y entonces dejamos de ser predecibles. Ser predecibles es una de nuestras metas porque así sabremos cada vez mejor, cuánto podemos tardar en entregar funcionalidad con valor para el negocio.
• Evitar hablar de "terminar tareas" y hablar más de poner en producción tareas que suman valor. No sirve querer terminar, sino querer desarrollar piezas que mejoran la experiencia del usuario. Cuando pensamos en terminar, es más fácil hacerlo mal (porque lo urgente quita de enmedio a lo importante). Rara es la semana que no se introducen nuevos requisitos en funcionalidad que estaba "terminada".

Esta semana estoy muy contento con la labor técnica del equipo:

• Se ha respetado en todo momento que todos los tests pasen
• Se han añadido tests para demostrar bugs
• No recuerdo que se hayan escrito métodos nuevos de más de 10 líneas.
• No se han introducido números mágicos ni código duplicado
• Se ha prestado bastante atención a la code review y los commits han sido muy claros.

Es importante vigilar bien que sigamos por el buen camino, porque estamos en un punto en que retroceder lo andado no es muy dificil.

Buen comienzo de semana a todos

Por este motivo, la reunion del lunes podrá estirarse hasta un máximo de una hora con tal de que todos podamos estimar y comprometernos a entregar determinada funcionalidad el viernes, o por lo menos a intentarlo.

Aunque nuestra hora de meeting son las 9.30am, el lunes desplazaremos la hora lo que haga falta para que estemos todos. Esta semana faltaron personas que al no estar en el meeting de planificación no pudieron aportar su conocimiento. Eso llevó a que yo escogiera como prioritaria una tarea que en realidad no lo era, porque ya teniamos una funcionalidad parecida, hecha en código existente pero no lo sabíamos. Era una funcionalidad que conocía la persona no estaba. La tarea que se ha implementado hacía falta pero no era tan prioritaria en el sprint de la semana que ha terminado.

Por otro lado existe preocupación porque no estamos colocando las clases en los namespaces más adecuados, ni los ficheros en las carpetas adecuadas. El problema es que si no están en un lugar intuitivo podemos repetir funcionalidad. Para esto la code review juega un papel importante, por lo que hay que seguir haciendo incapié en ella. A parte de eso, la persona que detecte que se ha puesto un fichero en el sitio incorrecto o un namespace que no corresponde, debe actuar de manera concreta, bien modificando el código o bien avisando por email a los compañeros, diciendo exáctamente por qué no es correcto y cómo solucionarlo.

En el código legado sigue habiendo horrores que nos están haciendo daño pero la preocupación por la ubicación de clases y ficheros es un tema recurrente así que vamos a intentarla solventar, tomando acciones concretas y constructivas.

Esta semana hemos resuelto graves problemas de concurrencia que teníamos. El trabajo ha sido duro porque hemos invertido mucho tiempo y escrito pocas líneas de código y eso da mala sensación, pero el resultado es muy bueno. Hemos aprendido bastante y sabemos qué cuestiones debemos considerar desde ya, para que nuestro código esté preparado para la concurrencia. Escribiré un post sobre nuestros descubrimientos con Linq2Sql y concurrencia pronto.

En las últimas semanas hemos hecho muy poco pair programming porque buena parte del equipo pensaba que así avanzaríamos más teniendo la fecha de entrega muy cercana. La realidad es que no podemos cuantificar si ha salido adelante más trabajo o no, pero lo que sí hemos hecho es introducir deuda técnica y aumentar en desconocimiento de lo que los demás hacen, lo que lleva a la duplicidad del código. Falta comunicación. Sabemos que la próxima semana volvemos a nuestro ritmo habitual, intentando hacer las cosas lo mejor posible y sabiendo que cuando dos personas trabajan juntas y bien concentradas, nos acercamos más a ello.