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

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

Resources for building a Rest API in .NET

Lectures

"JSON API: convention driven API design", by Steve Klabnik

APIs REST Usables by Javier Ramírez

Books and more Books in GitHub

url

Resources for Javascript

crockford.com
node.js jquery
lesscss
coffeescript
async comunications
A spanish javascript course
Some Stuff
Learning JavaScript Design Patterns A book by Addy Osmani

Apprenticeship Patterns - Guidance for the Aspiring Software Craftsman

I've just finished reading 'Apprenticeship Patterns - Guidance for the Aspiring Software Craftsman'.
It explains patterns to become a craftsmanship, for example: Be the worst in your team, Get feedback loops, Find a mentor, Share your Knowledge, practice, practice, practice!!! throw pet projects (breakable toys).

It's been very interesting. I recommend it. In the next future, I'll read again.

TDD en español

Con la idea de mejorar como programador, estuve buscando por internet, me topé con este libro: Dirigido por Test.

Para mí ha supuesto toda una revolución en la forma de programar. Descubrí lo que era la herencia, el polimorfismo, cosa que había olvidado desde la carrera (vergonzoso, pero cierto). Es una pena, que en la empresa en la que trabajo no me dejen hacer TDD (aunque algunas veces lo he hecho por mi cuenta), pero he aprendido a diseñar de una manera más lógica, cómo tiene que ser un programa informático y no ponerme como un loco a tirar líneas de código, que luego resulta una chapuza.