Going with the Workflow

Design thinking

Now we need to make some decisions. We have some logic that goes beyond Rails boilerplate. We need to parse that list of tasks and create Task instances out of them when the form is submitted. That code needs to go somewhere, and the unit tests we’re about to write against that code need to know where that place is. This is where the design thinking comes in the TDD process.

No matter where we put the actual coding logic, Rails will still insist on the existence of a controller, so we have the separate decision of whether or how to test whatever logic winds up in the controller itself.

Let’s start with the business logic. We’ll come back to the controller later on.

Business logic workflow

Three locations are commonly used for business logic that responds to user input beyond the common "pass the params hash to ActiveRecord#create" Rails behavior. Here are the options:

• We can put the extra logic in the controller. This is often the Rails core team’s preferred method, and if there isn’t much logic, it works perfectly fine. Usually, this location doesn’t work as well for complex logic. It’s challenging to test, awkward to refactor, and difficult to share if ...