TDD 2020

As the tests get more specific, the code gets more generic - Robert C. Martin
Prácticas = Principios(Contexto)

Más cercanos a negocio y no tan ligado a la implementación, en vez 'return string empty when is null', mejor 'allow null'
El nombrado de las pruebas
Refactorizar las pruebas
Intentar evitar las variables global o variables estáticas o singleton, que comparten estado
Que los test sean lo más sencillos posibles, sin bucles o condicionales. En una primera versión el tests puede ser complejo, pero una vez está en verde, podemos mejorarlo

Los tests parametrizado, quitan legibilidad porque estamos usando valores que a priori no tiene semántica y también quitamos los nombres de los tests.
los test no pueden garantizar la ausencia total de fallos en el software ni mucho menos

Fast (rápido) -> como mucho unos cuantos segundos
Independent (independiente) -> no tener dependencias con otras pruebas
Repeatable (repetible) inocuo, no altera el sistema
Self-validated (auto-validado) -> contiene aserciones
Timely (oportuno) -> el mejor momento para escribir un test, que resulta ser antes de escribir el código de producción


Xavi Gost: https://www.youtube.com/watch?v=S4Ueg64xfXQ
Dummy: no hace nada, simplemente para cumplir el contrato
Stub: solo datos
Mock: comportamiento (si ha sido llamado)

principios de XP
- Simplicidad: Lo que se busca, al dejar la puerta abierta a la implementación emergente y gradual (las cuatro reglas del diseño simple de Kent beck)
- Comunicación: conversaciones cara a cara, comunicación directa -> metáfora del teléfono escacharrado
- Feedback: just in time programming. La depuración se hace tediosa; arranca la aplicción que pare en los puntos de interrupción, cuando se puede hacer un test unitario.
- Respeto: desapegarse del código. No tomarlo como algo personal. Predicar con el ejemplo. El respeto del equipo se consigue dejando mejor código de lo que se encuentre.
- Valor: ser transparente y sincero.


builders para simplificar los datos de los tests



Property Based Testing
Mutating Testing

Transformation Priority Premise: PrimeFactors and WordWarp katas
https://martinfowler.com/bliki/PageObject.html

A video about pair programming by Birgitta Bockeler

I found a very interesting video about pair programming, this is the link video

I find it very interesting because she tells some hidden things that happen, when someone practices this technique.

I wrote down about that, here it is my notes

algunas cosas que he aprendido en estos años sobre el agile/xp

- búsqueda de la mejora continua. Quitando los desperdicios a lo largo de todo el ciclo del desarrollo de software.
- individuos motivados.
- búsqueda de la excelencia técnica.
- satisfacer las necesidades del cliente. Resolver con software el problema que tiene el cliente.

Técnica de las costuras y testear clases estáticas.

Refactoring and Design Skills for Test Driven Development SA2013 by Roy Osherove

--> SUT

public class LoginManager
{
    private IReadOnlyCollection<string> users;

    public LoginManager()
    {
        users = new[] { "john", "clare", "Mary", "Tom" };
    }

    public bool IsLoginOk(string user, string password)
    {
        log(user);
        return users.Contains(user);
    }

    protected virtual void log(string user)
    {
        Logger.Log(user);
    }
}

public static class Logger
{
    public static void Log(string message)
    {
    }
}

--> Test
public class LoginManagerShould
{
    private LoginManagerTesteable loginManager;
   
    [SetUp]
    public void SetUp()
    {
        loginManager = new LoginManagerTesteable();           
    }
   
    [Test]
    public void return_false_when_user_is_empty()
    {
        var result = loginManager.IsLoginOk(String.Empty, "password");
       
        Assert.IsFalse(result);
    }
   
    [Test]
    public void return_false_when_user_is_null()
    {
        var result = loginManager.IsLoginOk(null, "password");
       
        Assert.IsFalse(result);
    }

    [Test]
    public void return_true_when_user_is_valid()
    {
        var result = loginManager.IsLoginOk("Tom", "password");
       
        Assert.IsTrue(result);
    }
}

class LoginManagerTesteable : LoginManager
{
    protected override void log(string user)
    {
    }
}

Devil´s advocate technique

This is, in a nutshell, the Devil's Advocate technique. The intent isn't to break the software by sneaking in defects, but to explore how effectively the test suite detects bugs. In the current (simplified) example, the effectiveness of the test suite isn't impressive.
                                   source: https://blog.ploeh.dk/2019/10/07/devils-advocate/

learning videos

Patterns of Refactoring by David Donahue

DDD by Vaughn Vernon

Programming by Carlos Buenosvinos

TDD resources

I´ve found some resources about TDD, some of them are in spanish.
https://groups.google.com/forum/#!forum/tddev-sp
https://groups.google.com/forum/#!forum/artesanos-de-software
https://groups.yahoo.com/neo/groups/testdrivendevelopment/conversations/messages
https://groups.google.com/forum/#!forum/growing-object-oriented-software
https://groups.google.com/forum/#!forum/clean-code-discussion

Refactoring TripService By Sandro Mancuso in Meetup Software Craftsmanship Madrid

Some days ago I was in meetup software craftmansip madrid
This is the kata : Trip Service Kata
This is my solution: Solution of TripService Kata
I've learned that it is very important the name of the methods, due to the semantic of them and the meaning of the code.

Also I've watched this video. Sandro Mancuso solves this exercise. I recomend it.

Some notes about book "Extreme Programming Explained: Embrace Change"

=== eXtreme Programming ===

-- VALUES --
-Comunication --> Open honest Comunication, hones measurement
- pair programming
- unit testing
- task estimation
programmners, managers, customers

-Simplicity
- writing tests gives you focus for just how simple the system can be

simple systems are easier to test

-Feedback
- sort term delivery 1 to 4 weeks
- puts the most value features in production as soon as possible
- writes tests gives you feedback about the state of the feature

The more feedback you have, the easier it is to communicate

-Courage

-- PRINCIPLES --
-Rapid feedback
-Assumed simplicity: YAGNI, DRY
-Incremental changes: smalll changes, step by step is better than on big change
-Embracing change
-Embracing change

-- PRACTICES --
-The planning game
-Small releases
-Metaphor
-Simple design
1 run all tests
2 has no duplicated logic
3 states every intention importan to the programmers
4 has the fewest possible classes and methods
-TEsting
-Refactoring
-Pair programming
-Collective ownership
-Continuous integration
-40 hours wekk
-On site customer
-Coding standards


Work with people´s instincts, not against them.
People like winning.
People like intercting with other people
People like being part of a team
people like being in control
People like being trusted
People like doing a good job
People like having their software work

activities: coding, testing, listening, designing

- The code must communicate everything yo want to communicate
- The system must contain no duplicate code (eliminate all the duplicated logic in the system)
- The system should have the fewest possible classes
- The system should have the fewest possible methods

interesting reference about XP

link

Charla interesante sobre cómo mantener los tests unitarios limpios

enlace

Propety Based Testing

I've discovered a video that talks about tdd and the talker spoke about property based testing. In this moment I didn't know about it, but googling I've found a good explanation here

Playing with wallabyjs

Some time ago, I've dicovered wallabyjs. It is a test runner like ncrunch but for javascript.
I've done a little kata with Atom as an IDE

 It's a good product for tdd.

Lean Code Kata

Yesterday I was in an event at Software Craftsmanship Madrid. It was about lean code. The result of the exercise lives in my repo at Github.com. The code could be refactored. But I am learning that early refactoring could be a wrong decision for the future.

Code Kata: Rotate An Array In javascript, with grunt and expect

the description
the code

Apuntes de la charla de Bonilla sobre los equipos para ser brillantes

Bonilla - Equipos para ser brillantes  --> video de la charla

1._ Mantener el flow. Minimizar las interrupciiones. Proteger el tiempo haciendo uso de pomodoros

2._Alimentar el cerebro
-Organizar sesiones técnicas
-Comer el 20 minutos y los 40 restantes dedicarlos a ver vídeos comentar
-Montar un grupo de usuarios/estudio una vez al mes

3._Reconocer el trabajo. Dar las gracias:
-El trabajo vale para algo
-Reconocimiento de las pequeñas victorias
-Para cualquiera, también para los pobres becarios
-Reconocmiento entre compañeros

4._Report Robot
-Automatizar
-Compartir la información con todos

5._Dog fooding. Probar el propio software que se hace
-Alpha testing
-Es doloros
-Es entretenido
-Da feeback muy rápido

6._Celebra un día especial con los compañeros
-Se hace piña
-Las personas son buenas, el problemas son la circunstancias

7._Experimentar
-Motivación <-> innovación

Algunas frases que he escuchado que me han gustado:
Good programmer, good comunicator.
El programa lo que hace es contar un cuento.
Los programadores lo que hacemos es contar historias.

Algunos trucos para generar código limpio

Hace unas semanas estuve en un curso de introducción al TDD, dado por Carlos Ble.
Estas son algunas de las ideas que apunté:

.Código.
-No escribir ninguna línea de producción sin un test que esté en rojo.
 -formas de hacer tdd: tdd inside-out <--> tdd outside-in
 -Escuelas de tdd: school U.K. - school U.S.A.

 -Programar con método. Ser metódico. Disciplina y esfuerzo.
 -Escribir código para la máquina o para las personas: profesionalidad. Escribir código para otros seres humanos.
 Poner cuidado en el código.

 -Libro: Clean Code - Robert C. Martin
 -Videos: cleancoders.com

 -No solo un punto de retorno. Cuando antes se termine, mejor, para no poner ruido al código.
 -Un método no debe de tener más de 5 líneas.
 -Método hagan una cosa --> SOLID
 -Métodos que sean de 2 ó 3 líneas, con un nombre muy muy bueno. Mal nombre es contra-producente, para no entrar a ver lo que hace.
 -No comentar el código. Salvo un frameWork, una api y una clase añadirle la información de su contexto. Salva guardar la expresividad del código.
 -Pensar antes de añadir un comentario, para no mentir y no estar invirtiendo tiempo en el mantenimiento.
 -La función ideal no debe de tener parámetros. Puede tener como máximo 3 parámetros, pero no parámetros booleanos. Si tienes demasiados parámetros tiene que pasar un objeto.
 -Clases no tener más de 2 ó 3 público y 2 ó 3 métodos privados. Con una cantiadad de 25 y 200 líneas.
 -Nada de duplicidad y nombres expresivos.
 -Números mágicos

.Unit Test.
 -Agrupar los test, por contexto.
 -Test repetible e inocuo. Si trabaja con la base de datos, luego tiene que limpiarla.
 -Los test, no tienen que depender, unos de otros.
 -Test muy rápidos y unitarios.
 -No hay verdades absolutas
 -Test de integración, necesita un entorno de verdad, igual al de producción. Comprobar integración con los sistemas.
 -Los test de base de datos, son de end2end, pero se hacen al final, son costosos y tienen que ser pocos, porque son muy lentos
-Dejar una línea entre Arrange, Act & Assert.

 .Doubles.

-Cuando un objeto tiene varias dependencias, es mejor hacer uso de una factoria.
-Stub devuelve cosas, no tiene memoria
-Spy, tiene memoria, recuerda lo que ha pasado
-Mock, tiene memoria, y falla si se tiene que hacer otra llama y no se hace.


También hicimos una kata, para validad contraseñas, con las siguientes reglas:
-Al menos 4 carácteres.
-Al menos un número y una letra
-Al menos una mayúscula
-Al menos una minúscula


El resultado está en mi cuenta de github


Me gustó mucho el curso, por todo.

Resources about S.O.L.I.D. & Design Patterns

programación sólida
arquitectura sólida

Design  Patterns

Resources about TDD

I´ve finished a kickstart courde about TDD, with Carlos Ble

Some resources about this topic:

• James Shore
• orfjackal
• Kent Beck
• StackOverFlow
• cfp.us.es 
• the programming chronicles 
• iwt2 
• aprendiendotdd

Nice ecosystem software

1. Quality tests – sometimes TDD, sometimes test first, and sometimes test after.
2. Refactor to your heart’s content – if you’re afraid to change code because it might break something, you have problems. Follow SOLID principles as best as you responsibly can and you’ll have fewer problems here.
3. Continuous integration – make sure everything is working all the time. It helps in the long run (and by long run, I mean tomorrow). Oh, and by CI, I mean CI done right.
4. Collective code ownership – everybody owns this feature; it’s not just my own. a.k.a. No silos. Also, your victories must be shared, but your failures are also not your own.
5. Deploy early and often – The best time to deploy a feature is the moment it’s declared “Done” (or Done, done, done). The longer the span between this time and delivery, the more likely it is to fail.

Source