On Saturday I was in the # coderetreat Donosti. We present Enrique Comba, made master of ceremonies, raising the issue and giving us the steps to practice in each iteration.
I encourage you here to organiceis this event where you can, in fact no need to bring any stars, just be willing to learn one day and have fun.
has been a very interesting day, practicing a bit of programming, TDD. I realized, first, that was very rusty, and second, that I have much to play to fully understand the implications of TDD. Why doing good means scheduling TDD well, each time wondering why you put the code you're writing, and understanding the reasons of design.
What
The first two, they were free, without "putadillas" suggested by Henry, creoq ue almost all begin to design or a board, a universe, a few cells, etc ... there was a god who designed considering the game:)
principial My discovery is that we began to do TDD from a point of issue in which to begin the tests had taken modeling design decisions the problem. Yes, even before the tests.
This already made me nervous and the second iteration, with @ sharpbites proposed to start with what would be the beginning, a game interface, which resolved the issue. An acceptance test, now, more in line (I think) of a BDD approach. And we get stuck, go if we get stuck. Why? That attempted to reach the solution we had in mind. In general, we all found it easier to worsen from lower levels of the solution, with a bottom-up approach.
Enrique proposed a solution that convinced me, but I'll to put into practice a few times. This is from the test of acceptance, problem definition (top-bottom), and make rapid development that leads to a first solution, even rude. Then do the bottom-up and go missing completing developments to make sure you have enough test cases and created a good design.
What we get is to have soon a first version, and then strengthen the design and development in detail.
0 comments:
Post a Comment