Table of Contents
Testing
Frameworks
Unitary testing
BDD - Behaviour Driven Development
TDD Test Driven Development
- Escribiremos los tests antes de empezar a escribir código de nuestra app
- Pensar en el estado previo a la ejecución y en el estado posterior a ella (precondición y postcondición)
- Pensar la estructura de clases, métodos, y propiedades
- Empezar a escribir los tests
- Empezar a escribir el código
I’ve been running some interesting experiments with developers. I’ll take a group of developers through a two-week training using test driven development. At first, I’ll ask them to develop some software that meets some basic requirements using the approach that is most comfortable for them except that they must write a test before writing implementation. But I don’t time-box them and I don’t tell them anything more than the requirements. Most of the time I see groups spent the first hour or more talking about what they want to build and how to design it. It’s typical for nearly an entire afternoon to go by with little or no code written. Then the next day I ask them to work on another set of requirements but to do it with no design. Very often I get asked, “Really? No design at all?”
I respond, “Do pants have pockets or do pockets have pants?” Of course, they answer that pants have pockets. Then I say “That’s the amount of design I want you to do.” In other words, just state the basic relationships between entities but go no further. Don’t figure it all out up front, in fact I ask them to start coding as soon as you see anything that they can code, first as a test and then make the test pass. If they know some piece of functionality they need then I have them write a test for it and then implement that test and do this over and over.
Developers are often quite hesitant to try this at first but when they do they often see that their velocity starts to increase significantly. I am often asked, “But what happens if we get it wrong?” I suggest that they change it when they find a better approach. What we learn from this is that changing our designs or our code is not that big a deal and often it’s far easier and less time-consuming than I trying to guess up front what the right design might be which in the end is just as likely to be wrong as starting with essentially no design.
Links
