book-rails-4-test-prescriptions#slow-down1 "In practice, the more complicated the problem is and the less I feel I understand the solution, the more purist I get, taking slow steps." book-rails-4-test-prescriptions#slow-down1
book-rails-4-test-prescriptions#a-passing-test-does-not-drive-you-to-change-code1 "In strict TDD you would avoid writing a test that you expect to pass, because a passing test doesn't normally drive you to change the code." book-rails-4-test-prescriptions#a-passing-test-does-not-drive-you-to-change-code1
book-rails-4-test-prescriptions#where-to-put-complex-controller-logic1 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 our options:
Put the extra logic in the controller. This is the Rails core team's preferred method, and if there isn't much logic it works perfectly fine. In my experience this location doesn't work as well for complex logic. It's challenging to test, awkward to refactor, and difficult to share if that becomes an issue. It also becomes confusing if there is more than one complicated action in the controller.
Put the extra logic in a class method of the associated model. This was my go-to move for years. It's somewhat easier to test, but still kind of awkward to refactor—Ruby class method semantics are a pain. It also makes the model more complicated.
Create a class to encapsulate the logic and workflow. This tends to be my first choice these days. It's the easiest to test and the best able to manage complexity changes as they come. The main downside is you wind up with a lot of little classes, but I don't mind having a lot of little pieces anyway. book-rails-4-test-prescriptions#where-to-put-complex-controller-logic1
This setup allows each test case to very clearly identify what makes it different from the other cases—the different task_string . In the previous version that information was buried in the noise of the common creation steps. The downside is that the nesting and indirection make it harder to trace execution, especially if you're unfamiliar with this testing style.
Myron Marston, the lead maintainer of RSpec, suggested that RSpec compound matchers can let us have the speed of a single spec and the precision of splitting the spec.
book-rails-4-test-prescriptions#break-existing-code1 When the main cases are done, you try to think of ways to break the existing code. book-rails-4-test-prescriptions#break-existing-code1