Makers Academy Day 8
Today we had some interesting discussions about design while carrying out our weekend challenge coding review. We were introduced to Kent Beck’s Four Rules of Simple Design. The below chart ranks these rules in order of importance, with the ‘Passes the Tests’ rule shown as a firm priority:
Over the last week we have focused on Test-driven Development, religiously following the Red-Green-Refactor pattern. Something I will reflect on here is my experience of writing tests so far, and how I’ve come to see them as powerful communication tools.
When I began writing tests I found the process quite mechanical. I knew I was meant to start with the test because it was good practice, but didn’t immediately appreciate how this in turn was shaping my code.
Having been introduced to User stories last week I became very fond of drawing out a very basic domain model which helped to communicate the code that needed to be written. On the weekend challenge however I realised I had drawn out 6 domain models of stories prior to writing a single line of a test. In hindsight I think a better approach would have been to write 1 or 2 user stories & then begin writing tests. There were many code related factors that altered my domain models, but which I couldn’t have known until I began to write the program. My 6 readymade domain models therefore ran the risk of being too prescriptive, and on a bigger project could have hindered the code rather than helped it.
As I wrote more tests I came to appreciate that the test messages were a really helpful set of instructions about what an object could or couldn’t do. It gave me a very detailed breakdown of an object and how it interacted with different messages in the code. Having the constraint of a single line to describe the test, forced clarity to what I was trying to achieve.
If you can’t explain it simply, you don’t understand it enough. — Richard Feynman in RiverGlide, BDD & The Feynman Technique by Antony Marcano
These messages acted as a guide for me developing the programme, and served the purpose of a log to communicate to other developers important information. This also led me to think about the difference between a test message and a commit message. I came to the conclusion that a commit message shouldn’t duplicate a test message; if they both gave the same message then it was likely that my commit was too premature. My commits began to communicate the high view of the feature I had built, E.g. ‘The airport can now fly a plane’. Whilst my tests gave specific instructions about the conditions of that feature, E.g. ‘does not land a taken off plane’.
The tests were also a flexible space to adapt the needs of the programme. As more features were added for instance, some tests became redundant and were deleted or needed to be updated.
During my time at Makers Academy, I’d like to hone my ability to ‘translate’ user stories into tests and use these to efficiently communicate the code.