Un solo valor de retorno
Hay un mal que se esta extendiendo por la aplicación en las últimas semanas. Es el ResponseDTO. Es un objeto plano, tiene un campo "success" de tipo boolean y un campo "message" de tipo string. Debía llamarse Response pero colisionaba, así que se quedó con un mal nombre. Si le hubiesemos llamado ControllerResponse seguramente no se hubiese usado en las otras capas de la aplicación porque hubiese dado más pistas a quienes lo fuesen usar, de que su lugar es la capa controller. Sin embargo se ha colado en muchas capas de backend y no es una buena práctica:
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.
Filed under Planeta | Comment (0)
Cleaner interaction tests
Note: this post will probably evolve, the text will be updated as I need it.
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:
- You want to avoid a database call just to keep the test unit fast and repeatable (stub the method - use a stub object)
- You want the method to return some value to simulate the response (stub the method - use a stub object)
- 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.
Filed under Planeta | Comment (0)
Mockito Vs Moq
Don't be confused, the title is just to get your attention. This is not a benchmark between Mockito and Moq. I need to explain some differences to my teammates so that the transition between Mockito and Moq is softer for them.
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
Javascript, an acquired taste
You hate it, you love it
You start hating it but you might end up having so much fun with Javascript. It takes time to acquire the taste and enjoy the powerful capabilities that annoy you at the beginning. This is my experience learning this popular language.
Take into account that my opinion is based on just a few months of experience with Javascript as a language, not just a tool to manipulate the DOM (html and css). It will probably change along the journey.
The white box
Being used to languages like Python, I'd say Javascript is a white-box language while Python is a black-box one. That is, you don't really need to read books to start coding in Python, you just see some example code, try some lines and usually its execution behaves as you expected. It feels so natural. That is not the case of Javascript, its rules are not natural at a first glance. In fact, you have to know very well how the interpreter makes decisions. If you make a mistake writing some code that wouldn't compile or would raise an exception on other programming languages, Javascript will instead try to execute the code. And will probably traverse all the execution path. Because it doesn't fail, this behavior can be very confusing and hard to detect. You wish the interpreter to tell you that, you made a mistake and you probably didn't want to write what you did, you don't want the execution to continue. That is the feeling at the beginning. On the other hand, as time goes by, these capabilities turn out to be so powerful in terms of implementation choices and performance tuning.
Unfortunately coding for performance tuning leads to code that is hard to understand and maintain.
TDD is a must
We've been pairing and test driving our Javascript code these months using Jasmine. I feel that the impact of BDD on Javascript is bigger than on any other language. It's mandatory. I don't want to write a single line of production code if there is no failing test asking for it. Because Javascript forces me to be smarter than I am sometimes and ocuppies part of my mind with subtle implementation details that moves me away from writing code that expresses the business domain, the semantic of the actual business problem to solve.
If I don't write a test, a specification that clearly states what I expect the code to do and see it pass, I can't bet that it will work just by looking at the production code. It would feel like gambling.
There is a tone of patterns to avoid tipical Javascript mistakes. There are many books on the subject. Experts advise you techniques like, "check the type of the arguments the function receives, to make sure you get what you expect". But then they tell you that "instanceof" operator might not work if the inheritance wasn't implemented properly. It is overwhelming. I tell you a secret... you don't need to master all those patterns if you test drive your code! You don't have to worry about all possible usages of your code if it's you or your team who are going to consume it, because the specifications are already thought, written and are executable.
I always prefer "duck typing" than asking for the type of the arguments. I usually prefer to let Javascript evaluate conditions using its coercion rather than using strict operators like "===" or "!==". Because if you write code for humans, it is better to say:
"if (userExists)"
than
"if (userExists === true)".
So the approach and the concerns are totally different when you test drive the code. The productivity gain is brutal. Javascript is too expensive to work with if you can't guarantee all the time, that your code functions as you inteded it to be.
If for some reason I would not be able to develop with BDD, I would code with Coffescript rather than Javascript
The approach is totally different if you are writing a framework. Frameworks are too general, they are horizontal, not vertical so there is no business semantic on them. So yes, for frameworks you should be a Javascript power ranger.
OOP or Funtional?
Javascript is not a classical objet oriented language. There are no classes. However is a great language for object oriented programming! Don't be confused with this. If you know the object oriented paradigm, you just need to know how to implement polymorphism, composition and so on. The discussion on "there are no classes, there are prototypes", is superfluous. It is an implementation detail I don't care about. I don't think that is really important because I can express behavior with objects and model the domain the same way I would do it in Java. Rather than using "class" and "extends" I would use "constructor stealing along with prototype chainning". But it's the same tool
On the other hand, javascript is a great language for functional programming too It is actually more used as a functional language than as an OOP one. It is very common to pass functions as parameters and things like that.
You can approach different paradigms with Javascript. My advise is to not mix them together though.
Programming the UI is fun again!
I used to write desktop applications using Delphi, pyGTK and Windows Forms at the beginning of the past decade. When the web started getting mainstream, it was sad to say goodbye to all the best practices learned all those years. Used to the power of event oriented programming, rich components, data binding, and design patterns in general, developing for the web felt a step back. During the past decade there have been many attemps to mimic the old desktop in the web; portlets, asp webforms, and so on. None of them made developers happy, so the Model-View-Controller (MVC) pattern came to the rescue. However, dealing with the UI is still something developer don't really use to enjoy. DOM manipulation has been a pain in the ass with every browser having different behavior and API. I've been trying to avoid it until now and, to be honest, I am happy to not have invested my time fighting with problems that jQuery handles for me nowdays.
Now, ECMAScript 5 is supported in all major browsers. jQuery and other frameworks make life easier. And there is something that we didn't have in the old desktop programming: the chance to programmatically interact with widgets (UI controls or components). Well there are some frameworks for that in the native desktop, by they came late. This means that we can write automated tests for UI behavior!
So now, we have the chance again to use event driven programming, to really implement patterns like the "observer" and many others. And we can test drive all of them!
We can develop semantic components that add domain knowledge inside UI widgets and make the user experience way better. There is no need for intrusive frameworks that tell us exactly all the layers to be used and how. Everything is ready to craft the code to make it express as much human knowledge as possible.
So we are taking the chance.
No need for MVC frameworks
In the first two weeks of the project we started using Backbone. In the first spike, we used the whole framework. A bit later, just the models and collections. Nowdays, we have completely got rid of it. It is a great framework, but we don't need MVC frameworks anymore on the client side because they are more restrictive than we need. We don't develop "screens", we try to create "smart components" that can be reused and provide a different level of abstraction. The screen is just a place holder for components that can be injected. With the rich UI programming that Javascript give us today, the paradigm has changed. It is time to retrieve practices from 15 years ago mixed with best practices learned in the latest years. I wouldn't port or copy exactly what we have been doing recently.
Filed under Planeta | Comment (0)
Don’t let mockito confuse you
Don’t let mockito confuse you
The new version of mockito comes with a new method: spy. Very useful feature but... bad name!
The mockito's "mock" method creates already a spy object. The "spy" method creates a "proxy" or "proxy spy" object. Totally confusing, isn't it?
The "mock" method is not really awful, because you can also use the double as a mock or just a stub, and it is common to use the name "mock" for all kind of doubles, although still confusing. The benefit from naming the double properly is that it helps programming by intention, which is a big part of Test Driven Development.
I would rename "mock" to "double" and "spy" to "proxy". Anyway, don't forget that, when using the mockito's "spy" method any single call that you don't explicitly stub, will reach the actual object. It is really useful to work with legacy code, in fact, we implemented it in pyDoubles, but using the method "proxy_spy".
Just make sure you understand what kind of test double you use and why. That is what matters in the end
Robolectric (I): Unit Testing en Android
En primer lugar, debes disponer de un proyecto Android, generado desde Eclipse o desde Línea de Comandos.
A partir del proyecto, y usando Maven, la instalación es inmediata. Simplemente hay que crear un fichero pom.xml en la raíz del proyecto, con las siguientes dependencias:
[... Cabecera del Proyecto ...]
<dependencies>
<dependency>
<groupId>com.google.android</groupId>
<artifactId>android</artifactId>
<version>2.3.3</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.pivotallabs</groupId>
<artifactId>robolectric</artifactId>
<version>1.0</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.8.2</version>
<scope>test</scope>
</dependency>
</dependencies>
[... Más etapas y plugins del proyecto ...]
Como es normal, nuestro proyecto Android debe estar estructurado siguiendo las guías de Maven, con el código de la aplicación dentro de src/main/java y el código de nuestros tests en src/test/java. En el caso de los recursos gráficos (strings.xml, layouts, imágenes, ...), estos deben mantenerse en la carpeta res, y no en src/main/resources, respetando la disposición de contenidos de Android). Para más información sobre cómo configurar Eclipse y Maven, el siguiente artículo es tremendamente útil y completo: http://unbeagleyyo.wordpress.com/2011/03/12/empezando-con-android-maven-robolectric-y-roboguice
Aparte de esto, sólo hay que tener en cuenta que la dependencia android debe tener un scope provided, y robolectric lo debe tener como test. Nuestros tests tendrán que ejecutarse con el Test Runner RobolectricTestRunner.
Y ahora ya podemos comenzar a realizar TDD. En este primer ejemplo, veamos cómo probar el flujo de ejecución entre actividades:
import static com.xtremelabs.robolectric.Robolectric.*;
import static org.junit.Assert.*;
import org.junit.Before;
import org.junit.Test;
import org.junit.runner.RunWith;
import android.content.Intent;
import android.widget.Button;
import com.xtremelabs.robolectric.RobolectricTestRunner;
import com.xtremelabs.robolectric.shadows.ShadowActivity;
@RunWith(RobolectricTestRunner.class)
public class HomeActivityTest {
private HomeActivity activity;
@Before
public void setUp() throws Exception {
activity = new HomeActivity();
}
@Test
public void testButtonShouldOpenSecondActivity() {
activity.onCreate(null);
Button button = (Button) activity.findViewById(R.id.button);
clickOn(button);
ShadowActivity shadowActivity = shadowOf(activity);
Intent next = shadowActivity.getNextStartedActivity();
assertNotNull(next);
assertEquals(SecondActivity.class.getName(), next.getComponent().getClassName());
}
}
En este primer ejemplo se instancia una Actividad inicial (
HomeActivity). Al presionar el botón que contiene, comprobamos que el control lo obtiene una segunda actividad (SecondActivity).Para conseguir nuestro propósito, Robolectric nos ofrece una Actividad especial llamada ShadowActivity, que publica una gran cantidad de métodos que normalmente no están disponibles en la clase
Activity. En este caso, se está usando el método getNextStartedActivity() que retorna la siguiente actividad añadida a la pila de actividades del proceso.Gracias a Robolectric podremos probar prácticamente cualquier situación de nuestras Actividades y Servicios de forma aislada. En los próximos posts iré mostrando las situaciones que he ido encontrando a medida que profundizaba en el desarrollo sobre Android.
Nota 1: Si después de realizar estos pasos aparece el error "error inflating layout/main" puede ser debido a que Robolectric no encuentra el API de Android o que está usando una versión incorrecta. A mi me funcionó añadir la siguiente línea en el fichero AndroidManifest.xml:
<uses-sdk android:minSdkVersion="8" />
Nota 2: Si aparece un error
ClassNotFoundException de la clase R, el motivo es que Maven y/o Eclipse no tienen la carpeta gen incluida. Aunque hay varias soluciones potentes (como maven-android-plugin), una solución temporal es añadir al fichero pom.xml el build-helper-maven-plugin:<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>1.4</version>
<executions>
<execution>
<id>default</id>
<phase>generate-sources</phase>
<goals>
<goal>add-source</goal>
</goals>
<configuration>
<sources>
<source>${basedir}/gen</source>
</sources>
</configuration>
</execution>
</executions>
</plugin>
Erlang en la #kataplaya
Erlang en la #kataplaya
Hoy decidimos desafiar a los #katayunos haciendo una #kataplaya. Una kata a 50 metros del mar, en un bonito pub playero. 
Aprovechamos el profundo conocimiento de Joel Reymont (@wagerlabs) del lenguaje Erlang y nos pusimos con el String Calculator en este lenguaje. Aquí se ve el código de la primera iteración, hecha con el mejor TDD que pudimos y un segundo snapshot de código demostrando potencia de Erlang pero dejando a un lado TDD.
Erlang es un lenguaje funcional, que NO está basado en el paradigma de la orientación a objetos. Debo confesar que me ha gustado mucho. Yeray Darias y yo hemos disfrutando viendo nuestras primeras lineas de Erlang
Me ha gustado más que Lisp y Prolog, aunque ya hace años que no uso ninguno de los dos, pero este parece más limpio (no hay miles de paréntesis juntos). Trabajando con un experto al lado como Joel, hemos podido ver rápidamente por qué Erlang tiene muy buena pinta para escalar. Por un lado, se maneja bastante a bajo nivel, lo que da sensación de ahorrar muchos recursos. Por otro, el estado no se guarda, se procesa. Y al menos en lo que hemos visto hoy, la gestión de la memoria es sencilla, no es como C. Por otro lado, la posibilidad de diseñar una funcion en distintos bloques dependiendo del patterng matching de los argumentos de entrada, evita bastantes bloques condicionales y pareciera que nos ayuda a escribir código más limpio.No te fies de este post como una review seria de Erlang, son sólo mis impresiones despues de dos horas de code kata, en una kata que además es trivial.
A ver para cuándo la siguiente #kataplaya