{"id":1732,"date":"2016-04-12T17:19:04","date_gmt":"2016-04-12T14:19:04","guid":{"rendered":"http:\/\/blog.adrianbolboaca.ro\/?p=1732"},"modified":"2020-01-15T16:53:09","modified_gmt":"2020-01-15T14:53:09","slug":"programming-by-wishful-thinking","status":"publish","type":"post","link":"https:\/\/blog.adrianbolboaca.ro\/2016\/04\/programming-by-wishful-thinking\/","title":{"rendered":"Programming by Wishful Thinking"},"content":{"rendered":"

Coderetreat: Programming by Wishful Thinking<\/h1>\n

Blog post series<\/h3>\n

This blog post is part of a series about coderetreat<\/a> sessions.<\/p>\n

Purpose<\/h3>\n

This session introduces the concept of top-down approach of Test Driven Development for a new feature.
\nBy following the steps you will be able to understand how to add thin top-down features that you can show very fast to your customers. Many of the features will work, even though you will not have a fully functional system, just because you have used stubs or fakes for the parts of the system that are not yet implemented.<\/p>\n

\"Programming<\/a><\/p>\n

<\/p>\n

Concept<\/h3>\n

You want to implement a feature using Test Driven Development starting from the user interface. We call this kind of development top-bottom, as opposed to bottom-up, when you start from the database.
\nLet’s say your system is brand new, and you need to start from somewhere. Because you want to be Agile, your first feature needs to be a vertical slice from the user interface to the data layer. You want to receive feedback as soon as you can from your stakeholders on the new feature.
\nHow do you do that?<\/strong>
\nOne solution: Programming by wishful thinking.<\/p>\n

The first step is to find the scenario you want to focus on. This means that the business is very clear and you can do a vertical slice of the requirements.<\/p>\n

Once you know what you need to do, you write an acceptance test. For that you need to implement the top and the bottom layer. This test will fail until you have implemented the last unit test.<\/p>\n

You start writing unit tests from the top layer (user interface) to the next layer (maybe a view or a model). If you need any information you create an interface or a function and create a stub. That stub will give you all the information you need. This is where you are doing some wishful thinking. Whatever you need and don’t have, think that you have it and write a stub for it<\/strong>. Working in this way will give you the opportunity to focus on the vertical slice, from the top layer to the bottom. Don’t get distracted implementing anything else, just write a stub.<\/p>\n

You continue to write code like that, writing tests on each layer until you reach the bottom layer. When the last test is implemented, the acceptance test should pass. This is when you can show your new scenario to someone for feedback.<\/p>\n

Outcomes<\/h3>\n

You will be able to understand better what top-down Test Driven Development is. Another important outcome is that you can understand one of the ways of doing Evolutionary Design.<\/p>\n

You can develop a product with a fast feedback cycle by using this method. Once a feature is finished you can show it to your stakeholders. They will come with improvement feedback that you can act upon.<\/p>\n

Remarks<\/h3>\n

The top-bottom Test Driven Development approach is very appropriate for web development. You pass through all the layers and write the needed tests, add the needed functionality. Nevertheless top-bottom is not that useful when writing algorithms, there I would recommend you to try a bottom-up approach to Test Driven Development.<\/p>\n

 <\/p>\n

During all the steps you are taking incremental design decisions<\/strong>:<\/p>\n