{"id":35,"date":"2015-02-04T01:58:33","date_gmt":"2015-02-04T01:58:33","guid":{"rendered":"http:\/\/codereporter.de\/?p=35"},"modified":"2015-02-08T10:10:41","modified_gmt":"2015-02-08T10:10:41","slug":"tdd-my-first-mayor-obstacle","status":"publish","type":"post","link":"https:\/\/codereporter.de\/?p=35","title":{"rendered":"TDD &#8211; My first major obstacle"},"content":{"rendered":"<p>For someone like me, new to development, it sounds really strange to write a test before having a function or product ready. But anybody at Makers Academy is a 100% convinced that the so called technique of \u201cTest Driven Development\u201d (TDD) is absolutely essential for writing good, maintainable code.<\/p>\n<p><strong>What it is and how it works (non-technically spoken)<\/strong><\/p>\n<p>In TDD developers at first break their problem down into objects and actions. In our first week\u2019s project we are dealing with the famous London &#8222;Boris Bikes\u201d. Those can be rented and occasionally they have to be fixed. There are some more objects like a van that comes to fetch broken bikes and so on&#8230; but let\u2019s focus on those bikes at first.<\/p>\n<p>The project is not about building a shiny website on which people can rent bikes. It\u2019s about inventing a model that reflects those processes in Ruby-code. I can make up a (code-)bike by writing:<\/p>\n<p><code>class Bike<\/p>\n<p>end<br \/>\nbike1 = Bike.new<br \/>\n<\/code> <\/p>\n<p>Between \u201cBike\u201d and \u201cend\u201d I can later on define, that our virtual bikes are initially in good conditions, until someone calls my newly invented \u201cmethod\u201d called \u201cbreak!&#8220; that breaks the bike (even though you might be interested in how people break the bikes &#8211; that&#8217;s [again] not part of the game). Building those objects and features doesn\u2019t seem to be so difficult at first. But actually it\u2019s really hard to find the details, the program should in the end focus on. I found myself thinking about the users and what they do when their bikes break somewhere on the way. But that\u2019s not part of my project. <\/p>\n<p>Back to TDD. Before we are allowed to invent our tiny complexity-reduced world, our coaches Stephen and Mihai expect us to write tests that will check the code we write.<\/p>\n<p><strong>Irritating <em>&#8222;natural language&#8220;<\/em><\/strong><\/p>\n<p>I don\u2019t know many developers but the ones I have heard talking about code were really excited about programming language that actually reads like English. From my perspective this is a very silly thing. I want to learn a language that my computer understands but this language turns out to be some awkward dialect of English. It\u2019s good that I can guess what a method called \u201cconcatenate&#8220; does or what happens when I use operators like &#8222;if&#8220;, &#8222;else&#8220; or &#8222;unless&#8220;. But there are so many ways to say that the docking station for bikes is full that are easier to guess than that one:<\/p>\n<p><code>it 'should not accept a bike if it\\'s full' do<br \/>\nfill_station(station)<br \/>\nexpect(lambda { station.dock(bike) }).to raise_error(RuntimeError, 'Station is full')<br \/>\nend<\/code><\/p>\n<p><strong>I trust them\u2026<\/strong><\/p>\n<p>Stephen would most probably say that this code needed some refactoring to be better readable and that there are a 1000 different ways to \u201csay\u201d this in code. I have decided to trust him and the other teachers. Obviously people can learn how to read and write this language fluently. And I really want to learn that as well.<\/p>\n<p>\u201cknow_code? if false &#8211; keep_reading. else \u2018hurray!\u2019&#8220;<\/p>\n","protected":false},"excerpt":{"rendered":"<p>For someone like me, new to development, it sounds really strange to write a test before having a function or product ready. But anybody at Makers Academy is a 100% convinced that the so called technique of \u201cTest Driven Development\u201d (TDD) is absolutely essential for writing good, maintainable code. What it is and how it&hellip; <a class=\"more-link\" href=\"https:\/\/codereporter.de\/?p=35\"><span class=\"screen-reader-text\">TDD &#8211; My first major obstacle<\/span> weiterlesen<\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[5],"tags":[7,6,8],"_links":{"self":[{"href":"https:\/\/codereporter.de\/index.php?rest_route=\/wp\/v2\/posts\/35"}],"collection":[{"href":"https:\/\/codereporter.de\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/codereporter.de\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/codereporter.de\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/codereporter.de\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=35"}],"version-history":[{"count":3,"href":"https:\/\/codereporter.de\/index.php?rest_route=\/wp\/v2\/posts\/35\/revisions"}],"predecessor-version":[{"id":39,"href":"https:\/\/codereporter.de\/index.php?rest_route=\/wp\/v2\/posts\/35\/revisions\/39"}],"wp:attachment":[{"href":"https:\/\/codereporter.de\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=35"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/codereporter.de\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=35"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/codereporter.de\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=35"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}